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I.  INTRODUCTION  AND  BACKGROUND  OF  SPLICE 

A.  DISCLAIMER 

The  ideas  and  opinions  expressed  in  this  thesis  are 
entirely  these  of  the  authors  and  do  not  necessarily  repre¬ 
sent  the  position  of,  or  an  endorsement  by,  the  Naval 
Postgraduate  School,  Naval  Supply  systems  Command  or  Fleet 
Material  Support  Office. 

Seme  terms  used  in  this  thesis  are  registered  trademarks 
of  commercial  or  government  concerns.  Rather  than 
attempting  to  cite  each  individual  occurrence  of  a  trade¬ 
mark,  all  registered  trademarks  appearing  in  this  thesis  are 
listed  below,  following  the  firm  holding  the  trademark. 

Department  of  Defense,  Washington,  D.C.  : 

Ada 

Digital  Equipment  Corporation,  Maynard,  Massechusetts : 

VAX,  ONIEUS,  LSI-11,  Q-  Bus 

B.  SPLICE  BACKGROUND 

The  present  Navy  Supply  System  consists  of  approximately 
60  Stock  Point  (SP)  and  Inventory  Control  Point  (ICP)  facil¬ 
ities,  all  running  the  Uniform  Automated  Data  Processing 
System  -  Stock  Points  (UADPS-SP)  on  Burroughs  medium  size 
computers  (E-3500  through  B-4800).  Normally,  each  SP  main¬ 
tains  two  of  these  computers.  The  supply  system  also 
contains  two  ICPs,  each  using  the  UNIVAC  U494.  Many  tran¬ 
sactions  entered  into  the  supply  system  are  processed  ir.  a 
batch  mode.  At  several  sites,  some  of  the  more  specialized 
applications  are  processed  on  smaller  '•standalone” 
computers.  Their  output  eventually  is  integrated  with 
UADFS-SP  using  an  offline  entry  system. 


The  Stock  Point  Logistics  Integrated  Communication 
Environment  (SPLICE)  is  being  developed  zo  augment  the  Navy 
Supply  Point  and  Inventory  Control  Point  facilities.  The 
main  objective  of  SPLICE  is  to  provide  economical  and 
responsive  support  capabilities  by  decentralized  communica¬ 
tions  [Hef.  1#p.1-2].  To  support  this  objective,  SPLICE 
must  meet  two  important  needs.  First,  the  increased  need 
for  interactive  communication  and  second,  the  need  to  stand¬ 
ardize  supply  site  interfaces.  Since  input  terminals  play  a 
major  role  in  meeting  both  of  these  needs,  SPLICE  is 
designed  to  efficiently  manage  the  myriads  of  input  devices 
that  are  and  will  be  available. 

In  short,  the  SFIICE  subsystems  will  act  as  a  front-end 
processor  to  the  current  Burroughs  hosts,  offloading  commu¬ 
nication  processing  from  the  hosts,  and  adding  interactive 
processing. 

C.  SPLICE  CONFIGURATION 

The  proposed  SPLICE  system  will  consist  of  standard 
hardware  and  software  located  in  minicomputers  at  each  SP 
and  ICP .  The  minis  will  be  tied  together  as  a  local  area 
network  (LAN)  and  each  LAN  will  be  connected  together 
through  the  Defense  Data  Network  (DDN)  . 

The  SPLICE  project  will  progress  in  several  phases,  the 
final  integrated  system  appearing  somewhat  like  Figure  1.1 
[Ref.  2, p.2-24].  Note  that  the  Burroughs  mainframes  are 
supported  by  the  SPLICE  subsystems  and  are  integrated  into  a 
LAN.  The  LAN  at  each  stock  point  is  tied  together  by  a 
common  internet--the  DDN.  There  are  also  plans  to  add  ether 
hosts  to  seme  of  the  LAN's.  [Hef.  2, p.2-23] 

Figure  1.2  [Ref.  2, p.3-3]  is  the  way  the  Fleet  Material 
Support  Office  (FMSO)  views  the  SPLICE  software  configura¬ 
tion  at  each  LAN.  The  Burroughs  hosts  will  be  running  in  a 


background  node,  processing  large  file  handling  actions, 
while  a  complement  cf  minicomputers  will  be  running  in  a 
foreground  aode.  The  minis  will  support  the  hosts  with 
communications  and  interactive  update  capabilities.  The 
envisioned  software  suite  is  centralized,  with  the  Complex 
Manager  acting  as  the  arbitrator  for  all  foreground  activi¬ 
ties.  This  implementation  will  provide  for  high  system 
availability  through  a  highly  redundant  hardware  and  soft¬ 
ware  configuration.  [Bef.  2, p.3-2, 3-3] 

D.  SPLICE  PROJECT  AT  BPS 

In  contrast  to  the  FMSO  design,  the  SPLICE  functional 
design  approach  being  used  at  the  Naval  Postgraduate  School 
is  directed  toward  developing  a  logical  or  virtual  LAN 
first,  thus  ensuring  that  the  functional  requirements  are 
satisfied.  This  is  done  by  developing  several  functional 
modules,  distributed  in  minicomputers  throughout  the  LAN, 
with  the  necessary  communications  protocols  to  support  them 
[Bef-  3],  All  functional  modules  will  operate  indepen¬ 
dently,  reacting  only  to  messages  from  other  modules.  As 
opposed  to  the  FMSC  concept,  there  is  no  notion  cf  a 
centralized  manager.  The  NPS  design  allows  for  higher 
system  availability  than  the  centralized  approach,  since 
functional  modules  can  be  moved  from  one  physical  node  to 
another,  without  changing  their  logical  addresses.  The 
proposed  functional  modules  will  include  the  following: 

•  Terminal  Management  (TM) 

•  Session  Services  (SS) 

•  National  Communications  (NC) 

•  Database  Management  (DEM) 

•  Feccvery  Management  (SM) 

•  fiesccrce  Allocation  (BA) 

•  Peripheral  Management  (PM) 


Figure  1. 3  shows  the  proposed  physical  view  of  the 
SPLICE  LAN  containing  functional  modules  in  a  network  of 
minis,  communicating  through  a  bus.  Other  supporting 

processes  that  are  necessary  for  interface  with  SPLICE  hard¬ 
ware  include: 

•  Euffer  Manager 

•  Local  Communications 

•  Message  Server 

These  processes  will  be  contained  in  each  of  the  physical 
processors  in  the  LAN,  corresponding  somewhat  to  the  "inter¬ 
face"  pcrticn  of  Figure  1.3.  In  addition,  each  functional 
module  will  have  its  cwn  copy  of  the  Message  Server. 

E.  FUNCTIONAL  MODULE  OVERVIEW 

The  discussion  in  this  section  will  be  limited  to  a 
general  overview  of  the  SPLICE  functional  modules.  Changes 
made  to  the  module  design  in  £Ref.  1],  assumptions  and 
interface  considerations  will  be  covered  in  a  later  chap¬ 
ters  . 

1 .  Terminal  Management  (T  M) 

This  module  includes  terminal  user  message  editing, 
screen  management  and  virtual  terminal  operations.  The 
Network  Virtual  Terminal  protocol  contained  herein,  will 
have  the  ability  to  convert  differing  terminal  formats  to  a 
standard  LAN  format.  It  will  also  give  the  user  the  capa¬ 
bility  tc  design  his  own  screen  format,  which  will  enable 
him  tc  tailor  his  system  to  his  own  needs.  Most  of  the 
network  sessions  will  up  between  Terminal  Management  and 
some  ether  module  (most  likely  Database  Management). 


Figure  1. 3  Proposed  SPLICE  Local  Area  Network 


2 


•  Session  Services  (SS) 

This  module  will  be  used  to  open  and  close  interac¬ 
tive  and  deferred  sessions  with  both  local  and  remote 
modules.  It  will  do  this  by  retrieving  both  the  logical  and 
physical  addresses  of  the  destination  module  from  a  Network 
Services  Directory.  This  directory,  which  will  include  the 
addresses  of  all  modules  within  SPLICE,  will  be  kept  current 
by  the  Network  Management  Center  for  SPLICE. 

Session  Services  will  also  contain  the  Mailbox 
Manager.  This  process  will  be  invoked  when  incoming  or 
cutgcing  messages  are  addressed  to  an  inactive  process  or 
LAN.  The  Mailbox  Manager  will  store  the  messages  in  the 
appropriate  mailbox  and  deliver  them  to  the  destination 
process  when  it  becomes  active  again. 

3  .  Database  Ma nagement  (DBM) 

The  functions  of  the  Database  Management  module 
consist  cf  database  query  processing  and  file  management. 
This  module  will  be  active  in  many  of  the  SPLICE  sessions, 
since  SPLICE  users  will  want  to  query  cr  update  their  data¬ 
bases  on  a  regular  basis. 

4 .  Recovery  Man agement  (RM) 

The  most  important  function  of  this  module  is  to 

attempt  recovery  from  error  conditions.  These  errors  condi¬ 

tions  include  reports  from  other  processes  concerning  ocnre- 
sponding  SPLICE  local  modules  or  remote  LANs.  RM  will  also 
be  responsible  for  Network  Services  Directory  maintenance. 
This  maintenance  will  normally  be  initiated  by  periodic 
updates  from  the  SPLICE  Network  Management  Center. 
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5.  Resource  Allocator  (RA) 

This  functional  module  manages  a  pool  of  shared 
resources,  including  memory  buffer  space  and  disk  drives. 
It  will  fill  requests  from  individual  Buffer  Manager 
processes,  allocating  more  main  memory  or  disk  storage  space 
to  a  process  that  has  exhausted  its  preallocated  space. 

6.  Per ipher al  Management  (PM) 

The  functions  of  this  module  will  include  processing 
commands  to  line  printers  and  card  readers  and  punches. 

7 •  Support  Processes 

Local  Communications,  Buffer  Manager  and  Message 
Server  processes  will  exist  as  servers  to  the  functional 
modules.  They  will  act  as  the  interface  between  the  modules 
and  the  lower  level  hardware  and  software  of  the  LAN.  Their 
main  functions  center  around  handling  message  traffic. 

F.  THE  DEFENSE  DATA  NETWORK 

1  •  SPLICE  Internetwork  Alternatives 

The  interconnection  of  SPLICE  LANs  by  some  long  haul 
means  would  result  in  a  real  improvement  over  the  off-line, 
AUTODIN  I  ccmmunicaticns  which  is  presently  used.  Such  a 
network  might  also  allow  for  SPLICE  users  in  one  LAN  to 
perform  ether  new  types  of  operations  such  as  interactive, 
on-line  queries  of  a  database  in  a  distant  LAN.  This  all 
equates  to  the  use  of  some  long  haul  communications  circuits 
with  seme  means,  as  a  minimum,  to  facilitate  and  manage  the 
flow  of  data  or  messages  between  SPLICE  LANs. 

Options  for  providing  these  circuits  include: 

1.  Establishing  a  dedicated  point-to-point  or  a  distrib¬ 
uted  network  just  for  SPLICE  use. 
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2.  Contract  to  use  a  commercial  network  for  specific 


services. 

3.  Utilize  existing  DOD  systems, 
iiixhccrt  gcing  into  details,  suffice  it  to  say  that  options  1 
and  2  are  less  feasible  than  3,  especially  considering 
factcrs  such  as  cost,  security  and  survivability.  The  SFLICE 
project  accepted,  rear  the  outset,  a  commitment  to  use 
existing  EOE  systems.  This  selection  may  appear  as  a  fore¬ 
gone  conclusion  but  it  should  be  emphasized  that  the  ether 
two  options  have  been  selected  frequently  by  government 


a.  Host  InMen.nt  at  Ion 


b.  Hoit  Front  End 


c.  Terminal  Emulation  Processor 


Piaure  1.4  DDN  Host  Interface  Ootions. 


agencies  faced  with  similar  internetwork  requirements.  This 
trend  was,  in  part,  the  motivation  for  the  creation  of  the 
Defense  Data  Network  (DDN)  .  Previous  SPLICE  efforts  focused 
on  the  EEN's  predecessor,  AOTODIN  II  [Ref.  2],  but  the 
current  efforts  are  focused  on  utilizing  existing  ARPANET 
technology  in  developing  the  DDN. 

2.  SPLICE  Interconnect  ion  with  the  DDN 

As  depicted  in  Figure  1.4,  the  DDN  offers  prospec¬ 
tive  users  3  basic  interface  options  [Eef.  4,p.162].  The 
last  option  is  not  desirable  as  it  greatly  limits  the  DDN 
services  accessable  by  the  host.  The  direct  interface 
contradicts  cne  of  the  design  goals  of  SPLICE:  to  cff-load 
the  communications  overhead  and  software  from  the  host. 
Thus,  tfce  most  feasible  option  is  to  support  a  Host  Front 
End  Processor  ( HFEP)  approach.  The  HFEP  can  be  accomplished 
most  easily  by  one  of  two  standardized  configurations  as 
shown  in  Figure  1.5  [Ref.  4,p.56].  SPLICE'S  DDN  traffic 
requirements  are  not  anticipated  to  require  high  volume 
support.  It  is  conceiveable  that  the  interconnect  will  be 
supported  by  an  LSI-11  microprocessor  (or  other)  board 
installed  in  a  SPLICE  FEP  to  provide  for  part  of  the  phys¬ 
ical  linkage  to  an  IMP  gateway.  This  option  could  provide 
for  up  to  a  64  K E  per  second  transfer  rate. 

Cre  important  distinction  should  be  made  concerning 
the  HFEP  approach.  From  the  DDN  point  of  view,  the  HFEP  is 
supporting  a  "host".  From  the  SPLICE  perspective,  the  HFEP 
is  the  SEIICE  Ftont  End  Processor  (FEP),  and  in  DDN  termi¬ 
nology  it  is  the  "host."  There  is  a  requirement  to  imple¬ 
ment  the  host-to-f r ont-end  protocols  (HFP) ,  shown  later  in 
Figure  1.9,  in  whatever  is  considered  the  host 
[Ref.  4, p.164].  For  reasons  stated  earlier,  the  SPLICE 
approach  is  to  off-lcad  the  SPLICE  hosts,  and  to  place  them 
in  the  background  [Ref.  1,p.1].  Consistent  with  this 
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Figure  1.5  DON  Host  Front  End  Processor  Options. 

approach  is  to  consider  the  SPLICE  FEP  as  the  DDN  host.  One 
may  even  consider  NC  to  be  the  software  which  supports  the 
HFE?  approach. 

The  actual  interconnection  of  the  HFS?  would  addi¬ 
tionally  require  a  high  speed  modem  and  a  dedicated  communi¬ 
cations  circuit  to  the  nearest  D"*N  IMP  gateway.  All  of 
these  physical  interface  compoL'r.ts  have  considerable 
capacity  for  expansion. 

3 •  CCN  Protocols 
a.  Overview 

Using  the  DDN  naming  conventions,  four  major 
groups  of  protocols  exist.  These  are  depicted  in  Figure  1.6 
[Bef.  4,p.153]  to  represent  the  physical  locations  where 
these  prctccols  reside.  As  contrasted  with  the  ISO/CSI 
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Figure  1.6  DDN  Protocol  Hierarchy. 

reference  model  layers,  these  DDN  names  map  to  the  model  as 
shown  in  Figure  1.7  [Bef.  1  , p.5-6  ]- 

t.  Network  Access  Protocols 

Network  access  protocols  define  the  interface 
between  a  host  and  a  switching  node.  Only  hosts  or  their 
logical  eguivalent — such  as  a  Front  End  Processor  (FEP)  of 
SPLICE — are  supported  directly  by  a  switching  node  cr  IMP  or 
gateway.  These  protocols  encompass  tae  physical,  link  and 
network  levels  of  the  OSI  reference  model.  DDN  provides  a 
range  cf  options  for  these  layers  of  protocols,  so  as  to 
accomodate  the  great  spectrum  of  present  and  future  users. 
Ihese  protocols  are  illustrated  in  Figure  1.8 
[Ref.  4 , p. 1 56]. 
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Figure  1.7  DDN  Protocols  and  Corresponding  ISO  Protocols. 

Along  the  tcp  of  Figure  1.8  we  see  the  general 
categories  cf  protocols  of  the  DDN  design: 

•  The  1822  is  a  BEN  developed  protocol  which  is  currently 
in  use  in  the  ARPANET  C/30  IMPS  and  TACs. 

•  The  HDH  or  HDLC  Distant  Host  Protocol  spawns  from  isc*s 
(HCLC)  High  Level  Data  Link  Control,  which  is  actually 
an  offspring  of  IBM's  Synchronous  Data  Link  Control 
(SDLC)  . 

•  The  Very  Distant  Host  (VDH)  . 

•  The  Segment  Interface  Protocol  (SIP)  is  unique  to  the 
SACDIN  interface.  It  uses  the  Advanced  Data 
Ccmmunica ti cns  Control  Protocol  which  was  derived  by 
ANSI  from  lEM's  SDLC. 

•  Supporting  the  X.25  standard  should  provide  more  lati¬ 
tude  for  SPLICE  bidders  and  equipment  vendors.  This  is 
not  currently  supported  on  the  ARPANET  and  is  a  current 
design  effort  of  the  DDN. 


1122 


JJLFaMT  Meet -I1*  Protocol 

(»k  kit  l«td«r  with  logical  oddroeoing) 


HDM  Lin*  and 
Haaaaga  Con¬ 
trol 


Rcllakla  Trana- 
•laaioo 


llayne  framing 


Synchronous  Serial 

(US-232.  RS-422.  M1L-1BIC.  ate.) 


Figure  1-8  DDN  Network  Access  Protocols. 


All  of  these  access  protocols  are  interface 
protocols  between  the  switching  node  and  host  (or  SPLICE 
FEP)  which  it  serves.  They  permit  reliable  transfer  of  data 
into  and  cut  of  the  subnetwork.  They  also  provide  varying 
levels  cf  assurance  that  the  data  successfully  traversed  the 
network  and  provide  subnet  and  subscriber  status  informa¬ 
tion.  The  protocols  do  not,  however,  provide  for  the  reli¬ 
able  host-tc-host  or  peer  level  communication.  To  support 
this  and  ether  aspects  of  the  transport  level  protocols,  DDN 
provides  the  Transport  Control  Protocol  (TCP)  /Internet 
Protocol  (IF).  These  TCP/IP  protocols  could  be  implemented 
in  the  hosts  themselves  or,  as  in  the  expected  SPLICE  envi¬ 
ronment,  within  the  PEP  (or  possibly,  HFEP  to  the  SFLICE 
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Figure  1.9  Physical  Location  of  Interface  Protocols. 

FEP)  .  Cne  final  way  to  depict  these  protocols  is  as  shewn 
in  Figure  1.9  [Ref.  4,p. 162  ].  Figure  1.9  represents  the  DDN 
concept  and  SPLICE  will  likely  modify  this  in  consideration 
of  its  intent  to  write  its  cwn  application,  presentation  and 
session  layers.  The  interface  between  SPLICE  and  the  DDN 
will  thus  entail  the  correct  interaction  of  the  SPLICE 
National  Communications  Module  and  the  TCP/IP  protocols. 
The  SPLICE  FEP  must  provide  the  environment  to  support  this 
interaction . 


G.  THE  RATIONAL  COMMUNICATIONS  MODULE 


1 .  C  ve  r  vie  w 

The  National  Communications  (NC)  Module  will  serve 
to  interface  the  SPLICE  LAN  to  the  DDN  and  vice  versa.  In 
this  role  as  a  "gateway"  tc  the  DDN,  the  NC  also  isolates 
the  LAN  from  the  DDN  in  that  the  DDN  protocols  will  rot  have 
to  be  implemented  internal  to  the  LAN  [Hef.  5],  Because  of 
the  inherent  difference  in  speed  of  transmission  between  the 
LAN  (1-2  MBPS)  and  the  DDN  (9600-56  KBPS),  NC  must  control 
the  frequent  buffering  of  outgoing  message  traffic.  Closely 
associated  with  the  buffering  control  is  the  requirement  for 
NC  to  provide  for  sequencing  of  LAN  messages  and  message 
fragments.  This  is  in  part  due  to  the  requirement  that 
there  be  only  one  unacknowledged  message  for  a  given  session 
between  any  two  NC  modules  in  different  LANs 
[Hef.  1,  p. 28,34  ]. 

2.  Design  Gcals  cf  the  National  Communications  Module 

Seme  underlying  design  objectives  were  developed  for 
the  NC  module.  These  goals  resulted  from  consideration  of 
the  SPLICE  user  needs  as  well  as  the  planned  operation  of 
the  DON,  primarily  the  Transport  control  Protocol  (TCP)  : 

a.  Transparency  to  User 

The  user  should  be  provided  with  the  illusion 
that  there  is  only  one  global  SPLICE  network.  The  physical 
reality  cf  multiple  LANs  tied  together  by  the  DDN  should  not 
be  apparent  to  a  user.  Except  for  possible  transmission 
delays,  he  will  uiilize  a  process  in  a  distant  LAN  in 
exactly  the  same  way  he  will  utilize  a  local  process.  This 
will  be  accomplished  by  the  "hidden"  interaction  of  the 
user's  process.  Session  Services,  NC  and  the  DDN.  Thus,  when 
a  user  on  a  terminal  in  a  California-based  LAN  wants  to 
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query  an  on-line  database  located  in  a  Pennsylvania-based 
LAN,  be  will  open  his  session  in  the  same  way  as  he  would 
with  his  local  database  system.  This  requires  the  func¬ 
tioning  cf  the  NC  and  the  DDN  to  be  invisible  to  the  user. 

b.  Interactive  and  Deferred  Service 

Thera  may  be  times  whan  a  user  does  not  desire 
interactive  service  with  ancther  process  (local  or  distant). 
This  is  apparent  when  a  user  communicates  with  a  background 
processor,  where  processing  requests  and  transactions  are 
queued  for  later  batch  processing.  Another  example  similar 
to  the  previous  database  example,  would  involve  a  user  who 
wants  to  submit  a  job  to  a  distant  database  process.  The  job 
may  be  lengthy  and  he  may  want  to  do  other  things  while  the 
job  is  being  processed  by  the  distant  database  process.  What 
the  user  should  expect  is  that  he  can  send  a  deferred  (ncr- 
interactive)  transaction  no  the  destination  database  system. 
After  the  database  system  completes  the  transaction  it 
should  send  back  the  results,  which  the  user  can  cbtain 
during  a  future  (deferred)  session.  One  cf  the  basic  prop¬ 
erties  of  this  service  is  that  the  user  does  not  expect  an 
interactive  or  quick  turn-around  response  for  his  session 
message.  This  supports  the  notion  that  interactive  sessions 
should  be  given  preference  over  deferred  sessions  cf  equal 
precedence  or  priority.  For  NC,  this  means  that  interactive 
sessions  should  be  given  preferential  handling  over  deferred 
sessions  cf  equal  precedence.  This  will  help  minimize  the 
transmission  delays  that  an  interactive  user  might  perceive 
if  the  NC  is  supporting  his  session. 

c.  Precedence 

While  one  may  surmise  that  most  users  of  SPLICE 
will  operate  at  a  single  level  of  precedence  (probably 
Routine),  higher  priority  capabilities  should  bn  provided. 


The  DEN  will  support  Routine,  Priority,  Immediate,  Flash  and 
Flash  Override.  It  is  concievable  that  SPLICE  requisitions 
under  emergency  or  wartime  conditions  might  require  prece¬ 
dences  up  tc  and  including  Flash  message  handling.  Therfore, 
the  NC  should  be  able  to  handle  sessions  of  different  prece¬ 
dences,  and  should  clearly  process  messages  of  higher  prece¬ 
dence  before  those  cf  lower  precedence.  While  this  would 
need  to  te  implemented  throughout  the  LAN  FMs ,  it  has 
special  connotations  for  NC . 

One  should  note,  while  addressing  issues  of 
preferential  handling,  that  there  still  is  a  need  tc  handle 
control  messages  before  any  other  messages  [Bef.  1,p.26], 
All  this  has  the  effect  of  establishing  two  sets  of  prece¬ 
dence  queues  and  a  special  control  message  queue  that  all 
processes  will  maintain  for  servicing  messages.  The  control 
queue  will  contain  control  messages  and  will  be  serviced 
before  any  ether  message,  even  a  Flash  message.  The  ether 
queues  belong  either  to  those  with  interactive  messages  or 
those  with  deferred  messages. 

a.  TCP  Insurance 

TCP  is  functionally  specified  to  provide 
‘•...reliable  interprocess  communication  between  pairs  of 
processes  in  host  computers  attached  to  distinct  but  inter¬ 
connected  computer  communication  networks"  [Ref.  6,p.  1]. 
TCP  is  intended  to  provide  guaranteed  sequenced  delivery  of 
message  cr  message  fragments  over  the  DDN;  however,  SPLICE 
intends  tc  provide  a  level  cf  "insurance"  on  TCP's  guarantee 
[Ref.  1,p.34].  Specifically,  this  will  require  the  source 
NC  tc  employ  a  stop  and  wait  acknowledgement  method  whereby 
only  one  unacknowledged  message  or  message  fragment  will  be 
outstanding  (with  the  destination  NC)  at  any  time.  The 
source  NC  must  await  acknowledgement  by  the  destination  NC 
befere  any  further  messages  will  be  sent  for  a  particular 
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session.  This  equates  to  a  high  level  NC  to  NC  acknowledge¬ 
ment.  This  is  done  in  addition  to  the  acknowledgement  and 
sequencing  performed  by  TCP. 

e.  Insulate  IAN  from  DDN  Protocol  Overhead 

As  mentioned  previously,  the  NC  "gateway"  action 
also  serves  to  insulate  the  LAN  from  the  DDN  protocol  over¬ 
head.  Very  simple  and,  hence,  very  fast  protocols  can  be 
utilized  within  the  LAN  and  NC  will  support  the  transition 
from  the  simple  to  the  complex  protocols  of  the  DDN. 
Therefore,  our  design  should  insure  that  little  protocol 
overhead  is  induced  cn  the  LAN  side  in  order  to  support  the 
LAN  *  s  interconnection  with  the  DDN.  The  barrier  to  this  DDN 
overhead  must  be  constructed  within  NC. 

f.  Design  Independence  and  Modularity 

This  NC  design  is  being  attempted  in  the  pres¬ 
ence  cf  seme  very  key  unknowns.  The  hardware  and  the  oper¬ 
ating  system  of  the  front  end  processor  is  net  presently 
fixed  nor  is  the  software  (or  hardware  for  that  matter) 
implementation  of  TCE  known.  One  can  speculate  at  great 
length  about  these  unknowns  and  the  design's  critical  effi¬ 
ciency  could  fail  or  succeed  upon  those  unknowns.  Thus,  it 
is  imperative  that  this  design  retain  as  much  independence 
from  the  unknowns  as  possible.  To  that  end,  informa ticn- 
hiding  techniques  and  data  structure  modularity  are  felt  to 
be  important  design  requirements  for  this  stage  of  the 
project.  Where  possible,  one  should  isolate  the  system- 
dependent  calls  or  parameters  to  a  single  module.  This  will 
greatly  ease  any  implementation  of  the  design  as  well  as 
improve  its  portability  and  maintainability.  One  must 
certainly  note  the  arguments  against  such  modularity: 

"...modularity  is  one  of  the  chief  villians  in 
attempting  to  obtain  good  performance,  so  that  the 


designer  is  faced  with  a  delicate  and  inevitable 
tradeoff  between  gcod  structure  and  good  performance. 
Further,  the  single  factor  which  most  strongly  deter¬ 
mines  hew  well  this  conflict  can  be  resolved  is  non  the 
protoccl  but  the  operating  system.'1  [Ref.  7] 

This  design  effort  cannot  really  begin  to  measure  the  effect 
of  its  modularity  vis-a-vis  the  efficiency  issues,  and  only 
an  actual  implementation  will  reveal  such  flaws. 
Nevertheless,  the  NC  design  is  aimed  at  identifying  and 
addressing  all  the  NC  requirements  in  a  clear  high  level 
design  structure.  Shile  the  design  may  not  ultimately 
reflect  an  efficiency-tuned  implementation,  it  should 
provide  a  valid  framework  for  the  initial  trial 
implementation . 

H.  DESIGN  APPRO ACH 

The  National  Communications  (NC)  module  will  provide  for 
the  use  cf  the  DDN  backbone  to  interconnect  dispersed  SPLICE 
LANs.  This  thesis  examines  how  NC  will  accomplish  this  by 
looking  first  at  the  interface  on  the  LAN  side  of  NC.  This 
amounts  tc  a  type  cf  "user’s  manual"  where  users  are  the 
ether  Functional  Modules  within  the  LAN.  The  requirements 
cf  the  NC  module  and  its  subcomponents  are  examined  next. 
Finally,  seme  of  the  pertinent  implementation  issues 
concerning  the  NC  and  other  SPLICE  modules  are  addressed. 
This  work  is  intended  to  explore  the  details  of  the  SFLICE 
modules  (especially  NC)  ,  and  as  a  first  effort  towards 
actual  implementation,  one  must  anticipate  that  the  NC 
design  will  evolve  with  later  work  on  the  project.  A  number 
cf  previous  SPLICE  concepts  needed  careful  compromising  and 
refinement  as  the  NC  design  evolved.  It  is  thus  expected 
that  future  work  will  result  in  similar  design  tradeoffs  as 
the  ether  SPLICE  modules  enter  a  more  detailed  design  stage. 


II.  NATIONAL  CCaaOHIC ATIOMS  MOD OLE  OSEB'S  MANOAL 

A.  PORFCSE 

This  chapter  will  give  the  user  of  the  National 
Communications  (NC)  module  a  general  overview  of  the  context 
in  which  NC  operates  and  the  information  necessary  to  inter¬ 
face  with  the  NC  module.  It  is  important  to  note  that  a 
user  cf  NC  is  considered  to  be  any  person  or  process  that 
must  communicate  with  NC. 

The  intent  of  this  user's  manual  is  to  describe  hew  NC 
and  its  users  interact,  but  net  why  they  operate  as  they  do. 
Reasons  for,  and  alternatives  to,  the  mode  of  operation 
discussed  in  this  chapter  will  be  covered  later  in  chapter 
3. 

B.  OPERATIONAL  CONTE1T 

It  is  felt  that  in  order  to  gain  an  appreciation  of  the 
interfaces  to  NC,  cne  should  first  understand  the  overall 
context  in  which  NC  operates.  This  section  is  designed  to 
give  a  more  detailed  look  at  the  operations  of  the  SPLICE 
functional  modules.  It  will  also  serve  to  highlight  the 
changes  that  have  been  made  to  the  design  of  the  SPLICE  LAN 
since  [Ref.  1]  was  published. 

1  •  SPLICE  Messace  Form  at 

The  SPLICE  LAN  will  operate  on  the  concept  of 
sessions  set  up  between  functional  modules.  Each  session 
will  be  assigned  a  unique  session  number  with  that  number 
being  used  in  all  messages  and  acknowledgements  during  that 
session.  Precedence  and  classification  information  are  also 
included  in  the  each  message.  Message  acknowledgements  can 
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Figure  2. 1  SE1ICE  Piggybacked  Message  Format. 

either  be  sent  separately  or  piggybacked  on  any  ether 
message  going  to  the  same  destination  module.  The  message 
format  fer  a  SPLICE  LAN  piggybacked  message  is  shown  in 
Figure  2.1. 


2.  Server  Processes 

As  the  LAN  operational  context  was  being  defined, 
some  general  functions  that  are  necessary  when  any  func¬ 
tional  module  processes  a  LAN  message  were  identified. 
These  functions  have  been  grouped  into  the  three  server 
processes  described  below.  The  intent  behind  these 

processes  is  that  at  least  one  copy  of  each  exists  in  each 
physical  processor,  and  their  functions  are  concurrent  with 
those  of  the  functional  modules.  ir  is  important  to  note 
that  each  functional  module  will  have  its  own  copy  of 
Message  Server. 

a.  Local  Communications 

Local  Communications  (LC)  will  mosr  likely 
consist  of  vendor  supplied  protocols  for  the  lower  two  or 
three  levels  in  the  ISO  model.  It  will  be  present  in  all 

physical  processors  as  the  interface  to  the  communications 
bus.  LC  will  be  invoked  by  the  Message  server  on  behalf  of 
the  functional  module  desiring  to  send  a  message. 

fc.  Buffer  Manager 

This  process  will  handle  allocation  and  deallo¬ 
cation  of  buffers,  keeping  a  table  of  active  and  inactive 
memory  space.  If  a  functional  module  runs  out  of  its  preal¬ 
located  memory,  the  Euffer  Manager  (311)  will  automatically 
request  shared  storage  from  the  Resource  Allocator.  The 
Message  Server  will  be  the  the  process  which  uses  BM  the 

most.  NC  will  also  use  it  for  deallocation  of  DDN  message 

buffers. 

c.  Message  Server 


The  Message  Server  (MS)  is  a  group  of  related 
message  handling  functions  that  will  be  colocated  with  each 


functional  module. 


The  functional  module  will  initiate  a 


local  send  with  a  pointer  to  the  buffer  containing  the 
message  to  te  sent.  MS  then  will  take  over,  adding  infcrira- 
tion  provided  to  it  by  Session  Services  at  the  beginning  of 
the  current  session*  This  information  consists  of  a  session 
number,  a  precedence,  a  classification,  and  the  source  and 
destination  addresses.  MS  will  also  add  the  message  number 
and  then  put  the  message  on  its  applicable  precedence  queue. 
Interactive  message  gueues  will  be  separate  from  deferred 
message  gueues,  with  interactive  gueues  being  served  before 
deferred  gueues  of  the  same  precedence.  When  the  message 
comes  to  the  front  of  the  queue  being  serviced,  the  message 
will  te  given  to  LC  to  be  sent  out  on  the  LAN  communications 
bus.  MS  will  handle  assembly  and  disassembly  of  multi- 
fragment  messages,  maintaining  control  of  an  outgoing 
message  until  the  last  fragment  has  been  acknowledged.  When 
the  message  acknowledgement  arrives  from  the  destination 
process,  MS  will  deallocate  the  message  buffer.  During  the 
period  between  a  message  and  its  acknowledgement,  no  new 
messages  may  be  sent  in  that  particular  session.  If  the 
message  remains  unacknowledged  after  an  appropriate  timeout 
period,  MS  will  retransmit  the  message.  If  no  acknowledge¬ 
ment  is  received  after  retransmitting  the  message  twice,  MS 
will  inform  Recovery  Management  and  Session  Services  of  the 
nonrespcnding  functional  module.  Session  Services  will 
prepare  an  error  message  for  Terminal  Management  to  present 
to  the  user  and  the  session  will  be  aborted. 

3 .  Functional  Modules 

This  section  provides  a  general  overview  of  the 
SPLICE  functional  modules  and  how  they  interact.  It  is  not 
meant  as  a  comprehensive  view  of  all  the  modules'  functions; 
therefore,  many  of  the  details  are  left  for  future  theses. 
In  each  functional  module  section  is  a  general  description 


of  how  it  handles  a  message  and  sets  up  and  maintains  a 


session. 

a.  Session  Services 

A  SPLICE  session  can  be  defined  as  a  network 
activity  which  involves  two  or  more  functional  modules,  all 
reacting  to  the  same  message  or  set  of  messages.  &  session 
is  initiated  by  an  open  message  to  Session  Services  (SS) 
from  one  of  the  functional  modules.  In  most  cases  the 
sessions  will  be  initiated  by  Terminal  Management,  but  there 
may  be  occasions  when  another  module  (e.g..  Database 
Management)  is  allowed  to  initiate  the  session.  During  the 
process  of  setting  up  the  session,  SS  will  look  up  the 
logical  and  physical  addresses  of  the  destination  process 
and  determine  if  it  is  reachable.  If  if  is  not  reachable  SS 
will  handle  the  session  through  a  mailbox,  where  it  will 
store  the  user's  messages  and  try  to  send  them  later.  If 
the  destination  is  reachable,  3S  will  add  a  new  session  to 
its  session  tree,  assigning  a  unigue  session  number  to  it. 
Precedence  and  classif icatior.  of  the  session  will  be  deter¬ 
mined  by  source  process  specification,  or  by  network 
default.  SS  will  send  the  addresses,  the  session  number, 
the  precedence,  and  the  classification  to  the  source  and 
destination  processes,  where  they  will  be  stored  by  the 
respective  Message  Servers.  Sessions  with  remote  processes 
outside  of  the  LAN  will  be  handled  through  NC,  and  will  be 
discussed  in  more  detail  later.  Nhen  the  session  is  set  up, 
SS  has  no  further  interaction  with  the  communicating 
processes  until  the  session  is  aborted  or  closed.  Each 
communicating  process  sends  its  messages  directly  to  the 
destination,  with  the  source  Message  Server  appending  the 
proper  information  to  the  messages.  A  close  or  abort 
message  will  cause  the  session  to  be  terminated  and  deleted 
from  the  session  tree.  Only  those  processes  involved  in  a 


session,  (with  tfce  possible  exception  of  Recovery 
Management),  should  be  allowed  to  abort  that  session. 

t.  Terminal  Management 


Terminal  Management  (TM)  is  the  terminal  user's 
interface  with  the  IAN.  As  explained  previously,  the 
Network  Virtual  Terminal  protocol  is  contained  here, 
enabling  the  user  to  communicate  with  other  users  on  the  LAN 
regardless  of  the  type  of  terminal  they  each  have. 

When  the  user  first  attempts  to  log  on,  TM  will 
verify  the  user's  password,  and  if  it  is  correct,  the  user 
will  be  allowed  to  create  a  session  with  the  functional 
modules  cf  the  SPLICE  Network.  When  opening  a  session,  the 
user  will  be  asked  to  give  the  classi ficaticn  and  precedence 
levels  that  are  desired  for  that  session.  once  the  classi¬ 
fication  and  precedence  levels  are  set,  they  will  remain 
fixed  throughout  the  entire  session.  If  the  user  is  author¬ 
ized  to  operate  at  the  levels  he  requests,  he  will  be 
allowed  tc  begin  sending  session  messages.  First,  TM  will 
convert  the  user's  messages  to  Network  Virtual  Terminal 
format  and  then  notify  Session  Services  of  the  user's  inten¬ 
tions.  If  the  user  wants  an  interactive  session,  a  full 
duplex  connection  will  be  set  up  with  the  destination  func¬ 
tional  module.  If  the  user  wants  a  deferred  session,  TM 
will  deposit  the  message  into  the  appropriate  mailbox  and 
request  Session  Services  set  up  a  session  between  the 
mailbox  and  the  destination  functional  module. 

c.  Recovery  Management 

This  module  will  handle  LAN  error  conditions,  tc 
include  all  the  error  messages  from  functional  modules 
reporting  a  nonrespcnding  destination  module.  Recovery 
Management  (RM)  will  check  the  status  of  the  questionable 
module,  and  inform  the  Network  Management  Center  (NMC)  if 


the  module  is  no  longer  reachable.  RM  will  also  oe 
receiving  periodic  update  messages  from  the  NMC  concerning 
the  status  cf  all  the  ether  LAN’s  within  the  network.  These 
changes  will  be  entered  into  the  Network  Services  Directory, 
to  which  RM  will  be  the  only  module  with  write  access.  RM 
will  have  built  into  it  a  statistics  gathering  process  that 
will  either  actively  or  passively  obtain  LAN  and  DDN  infor¬ 
mation  that  might  be  required  by  the  NMC.  Opel's  thesis 
[Ref.  8]  contains  a  detailed  discussion  cn  the  possible 
implementat iens  cf  the  statistical  portion  of  RM.  SM  will 
also  te  responsible  for  routine  or  emergency  backup  of  the 
LAN  state  for  recovery  purposes,  and  a  graceful  shutdown  of 
the  LAN,  if  necessary. 

d.  Resource  Allocator 

The  Resource  Allocator's  (RA)  main  function  will 
be  to  manage  a  pool  of  extra  memory  and  disk  space  to  be 
used  when  a  process  exceeds  its  normal  message  buffer  and 
workspace  allocation.  RA  will  be  called  by  Buffer  Managers 
throughout  the  LAN  tc  obtain  and  dispose  of  extra  resources. 

e.  Other  Modules 

An  explanation  cf  the  internal  operations  of  the 
ether  functional  modules,  which  include  Database  Management 
and  Peripheral  Management,  will  be  deferred  to  later  theses. 
Their  general  functions  are  defined  in  [Ref.  1].  The  impor¬ 
tant  point  to  note  here  is  that  these  functional  modules 
will  be  sending  messages  through  NC,  and  the  actions  of 
their  respective  message  servers  will  be  the  same  as  has 
been  described  above. 


C.  INTERFACES  TO  NC 

Interfaces  to  NC  can  be  viewed  from  three  bread 
contexts: 

1.  Interfaces  for  user  modules  physically  external  from 
the  processor  supporting  NC  but  local  to  the  LAN.  These 
interfaces  entail  control  or  data  messages  sent  or  received 
via  the  LAN  communications  bus. 

2i  Interfaces  for  modules  physically  internal  tc  the 
processor  supporting  NC.  These  interfaces  involve  parameters 
associated  with  either  control  or  data  messages  that  are 
passed  via  the  operating  system  or  run  time  environment  of 
the  processor. 

3.  Interfaces  between  NC  modules  in  different  LANs. 
These  interfaces  are  accomplished  using  data  messages  that 
are  sent  or  received  over  the  virtual  circuit  provided  by 
the  DEN . 

These  interfaces  form  a  group  of  user's  protocols  with  which 
modules  may  access  and  utilize  the  services  of  NC  (as  well 
as  other  5  F  LICE  modules)  . 


1  •  External  Mod  ule  Int  erf aces 

The  SPLICE  modules  that  interface  with  NC  include 
those  which  need  to  send  cr  receive  messages  to  or  from 
distant  SPLICE  LAN  Functional  Modules  (FM)  .  Terminal 
Management  (TM)  ,  Session  Services  (SS)  ,  Recovery  Management 
(RM) ,  Database  Management  (DBM),  Peripheral  Management  (PM) 
and  Resource  Allocator  (RA)  can  all  initiate  sessions 
(interactive  or  deferred)  that  require  the  interface  with 
NC.  Cne  must  consider  that  NC  may  also  need  to  interface 
with  any  cf  these  FM's  mailboxes  as  well.  The  suppert 
modules  knevn  as  Message  Server  (MS)  and  Local 

Communications  (LC)  were  examined  earlier.  These  modules 
play  key  roles  in  the  higher  level  interface  between  NC  and 
its  local  FMs. 
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As  discussed  earlier,  when  an  FM  wants  to  utilize 
NC,  it  does  so  through  its  MS  and  its  LC  modules  supporting 
the  particular  processor  in  which  the  FM  resides.  Similarly, 
NC  communicates  with  ether  local  FMs  through  its  copy  cf  MS 
and  LC.  What  is  passed  through  each  respective  layer  cf  MS 
and  LC  are  predefined  message  formats  (see  Appendix  D)  .  MS 
will  attempt  to  send  the  message  to  its  correct  destination 
and,  in  sc  doing,  it  will  handle  precedence  and  acknowledge¬ 
ments  on  behalf  of  the  FM  it  supports.  As  a  rule  of  thumb, 
local  acknowledgements  are  performed  at  the  MS  to  MS  level. 
The  basic  categories  of  these  messages  provide  a  framework 
for  discussion  of  the  FM  interfaces,  and  are  as  follows: 

a.  LAN  Control  Messages 

These  messages  will  be  routed  via  the  logical 
control  bus  [Ref.  1,p.26],  and  will  contain  a  response 
string  that  will  be  interpreted  by  the  receiving  FM 
(including  Nq  .  control  messages  are  utilized  for  the  mere 
critical  control  actions  such  as  system  recovery,  shutdown, 
error  conditions,  etc.,  that  demand  immediate  action  by  the 
FM.  For  example,  one  of  the  control  messages  that  NC  will 
send  or  receive  is  a  session  ABORT  message.  The  NC  design 
requires  that  control  messages  will  be  processed  before  any 
data  ressages. 

b.  LAN  Data  Messages 

These  messages  will  be  routed  via  the  data  bus 
and  contain  a  data  portion  cf  interest  to  the  receiver.  This 
format  should  also  be  used  for  most  message/message  fragment 
traffic  where  the  sender  has  no  acknowlegements  to  include 
or  "piggyback"  with  the  message.  This  format  will  also  be 
used  by  NC  and  the  respective  FM  for  setting  up  (opening) 
and  terminating  (closing)  sessions.  Additionally,  NC  will 
use  this  format  for  reporting  errors  to  users  and  Recovery 
Management. 
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c.  LAN  Acknowledge  men t  Messages 

This  message  is  routed  via  the  data  bus  and 

contains  re  data.  It  is  used  by  the  receiver  of  a  data 

message  when  there  are  no  other  data  messages  addressed  to 
the  source  functional  module,  on  which  to  piggyback  the 
acknowledgemen t .  This  format  may  frequently  be  used  for 
Deferred  sessions. 

d.  LAN  Piggybacked  Messages 

This  message  is  routed  via  the  data  bus  and 

combines  the  data  and  acknowledgement  information  described 
above.  It  is  utilized  at  the  Message  Server  level  whenever 
possible.  Note  that  the  ac knowlsgement  must  also  contain  a 
session  number  (see  Appendix  D)  . 

2.  Interna  1  Module  Interfaces 

The  NC  module  may  be  visualized  as  the  controller 
between  the  DDN  (TCP  module)  and  the  LAN  (MS  module)  ,  as 
shown  in  Figure  2.2.  MS  functions  as  NC’s  access  to  the  LAN 
and  TCP  functions  as  NC' s  access  to  the  DDN. 

The  MS  interface  to  NC  is  virtually  identical  to  the 
interface  between  MS  and  the  other  FMs  elsewhere  in  the  LAN. 
Parameters  such  as  buffer  pointers  to  messages  are  passed 
between  NC  and  MS.  Conceptually,  MS  is  a  process  executing 
concurrently  with  NC  (and  TCP)  ,  and  communication  (parameter 
passing)  between  NC  and  MS  is  accomplished  through  the  oper¬ 
ating  system  of  the  processor.  MS,  NC  and  TCP  are  perceived 
as  sharing  a  common  memory  managed  by  the  Buffer  Manager. 
Eesides  performing  allocation  and  deallocation  of  buffers 
for  the  FMs,  Buffer  Manager  should  also  support  deadlock 
detection  capabilities.  MS  is  assumed  to  handle  precedence 
and  control  messages  in  the  same  fashion  as  described 
earlier  for  NC,  with  data  message  precedence  queues  and  a 
separate  control  message  queue.  As  contrasted  with  the  NC  to 


Figure  2.2  LAN  -  NC  Message  Flow 


TCP  interface,  messages  passed  between  NC  and  MS  are  not. 
handled  by  a  stop  and  wait  acknowledgement  method. 

No  acknowledgements  will  be  performed  between  NC  and 
MS.  This  was  felt  tc  be  practical  because  NC  and  MS  will 
likely  be  implemented  in  the  same  physical  processor,  and 
communications  between  the  FMs  is  supported  via  operating 
system  facilities. 

Ccmmunicat ions  between  NC  and  TCP  will  be  accom¬ 
plished  as  for  MS — through  the  operating  system.  The  TCP  to 
NC  interface  must  rest  upon  the  minimum  TCP  functional  spec¬ 
ification  as  contained  in  [  Hef .  6  ].  More  details  of  these 
predefined  interfaces  are  contained  in  subsequent  chapters 
and  the  appendixes.  SPLICE  requirements,  as  addressed 
earlier,  added  the  stcp-and-wait  acknowledgement  method.  The 
dichotomy  of  interactive  versus  deferred  sessions  is  also 
supported  but  this  distinction  is  not  present  in  TCP; 
rather,  the  distinction  is  enforced  by  the  way  that  TCP  is 
utilized  by  NC.  Five  TCP  commands  are  required:  OPEN,  SEND, 
RECEIVE,  CIOSE  and  AEORT.  The  optional  TCP  STATUS  command 
was  net  inccrporated  as  part  of  the  NC  design. 

3.  NC  tc  NC  Interfaces 

The  NC  to  NC  interface  is  accomplished  ever  the 
virtual  circuit  provided  between  the  source  and  destination 
TCP  modules.  This  interface  is  utilized  at  various  stages  of 
sessions,  and  serves  to  synchronize  the  NC  modules  so  as  to 
reliably  control  message  flow  between  LANs.  The  most  basic 
part  of  this  interface  involves  the  stop  and  wait 
acknowledgement  scheme  discussed  previously.  The  source  NC 
will  control  sequencing  of  messages  to  the  destination  NC  by 
always  waiting  for  a  destination  NC  acknowlegement  cn  every 
data  message.  While  this  detracts  from  the  throughput  of 
the  NC  module,  it  provides  another  layer  of  insurance  upon 
the  TCP  guarantee  of  sequenced  delivery.  As  detailed  in  the 
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next  chapter,  this  acknowledgement  scheme  doss  not  include 
retransmission  by  the  source  NC. 

D.  CESSATION  CONCEPTS 

1 .  Message  Flow 

Tc  provide  a  graphic  illustration  of  the  message 
flow.  Figure  2.2  depicts  the  general  relationship  between 
modules  previously  described.  LAN  messages  to  and  from 
Session  Services  <SS)  are  required  as  part  of  opening 
sessions  in  each  LAN.  After  the  sessions  are  established, 
the  actual  data  message  is  routed  from  the  functional  module 
(FM)  ,  through  the  respective  Message  Server  (MS)  and  Local 
Communications  (LC)  ,  and  then  the  source  National 
Communications  (NC)  module  interjects  the  message  through 
TCP  to  the  CON .  Something  of  a  reverse  sequence  takes  place 
at  the  distant  LAN  before  the  message  finally  arrives  at  the 
destination  FM. 

2 .  Users  State  Ciagram 

Another  graphic  means  of  depicting  the  operation  of 
NC  is  shewn  in  Figure  2.3.  Figure  2.3  was  intended  to 
describe  the  general  states  of  NC,  but  it  also  captures  the 
general  states  applicable  to  intra-LAN  message  traffic  not 
involving  NC.  The  LISTEN  state  is  the  state  where  NC  has 
initialized  TCP  to  be  ready  for  any  incoming  or  outgoing 
messages.  NC  is  likewise  ready  to  react  to  service  any 
outgoing  message  requirement  received  from  its  MS.  In 
general,  a  particular  FM  must  first  initiate  actions  to  OPEN 
a  session  (interactive  or  deferred)  with  a  destination  FM 
before  any  actual  data  messages  may  be  sent.  This  requires 
an  interchange  of  information  between  the  source  FM  and  SS. 
After  insuring  that  the  destination  FM  is  reachable,  SS 
provides  the  destination's  physical  address  to  the  source 
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Figure  2.3  LAS  -  HC  State  Diagram. 

FM's  Message  Server.  After  the  destination  FM  acknowledges  a 
new  session  requirement,  the  state  changes  to  ESTABLISHED 
during  which  the  data  message  flow  is  accomplished. 

The  exception  to  this  sequence  of  steps  is  for  an 
incoming  (from  the  DCN)  deferred  session  requirement.  For 
this,  the  source  NC  will  actually  be  sending  the  first  data 
message  to  initiate  a  deferred  OPEN  in  the  destination  LAN. 
The  destination  (receiving)  NC  then  sets  up  a  deferred 
session  with  the  destination  FM's  mailbox  and  finally 
acknowledges  the  source  NC.  This  changes  the  state  to 
ESTABLISHED. 


Cne  should  note  the  two  actions  which  change  the 
state  from  ESTAE  to  LISTEN.  In  one  case,  NC  has  just 
received  a  “Deferred  Close  (IN)"  message  on  a  deferred 
session.  If  this  message  is  found  to  be  in  proper  sequence, 
the  receiving  NC  knows  that  it  has  already  received  all  of 
the  stream  of  messages  or  message  fragments  associated  with 
a  deferred  session.  No  more  messages  will  follow.  The 
destination  NC  can  thus  acknowledge  the  source  NC  and  then 
return  to  the  LISTEN  state.  There  is  no  need  for  the  desti¬ 
nation  NC  to  cycle  through  the  CLOSE  state.  In  the  ether 
case,  NC  has  just  received  an  ABORT,  and  like  all  ether 
ABORT  processing  from  other  states,  NC  takes  expeditious 
action  to  terminate  activity  on  that  session,  and  returns  to 
the  LISTEN  state.  Analogous  to  TCP  actions,  NC  does  not 
acknowledge  ABORT  messages.  ABORTS  may  be  called  as  a  result 
of  source  or  destination  user  processes,  TCP  or  DDN  interac¬ 
tion  or  ether  causes  such  as  LAN  shutdown  or  recovery. 
Under  these  circumstances,  acknowledgement  of  an  ABORT  is 
not  necessary  or  may  even  be  undesirable. 

The  other  state  changes  are  more  intuitive,  based 
upon  either  user  CLOSE  or  ABORT  messages.  This  state  diagram 
is  net  meant  to  reveal  the  finer  details  of  how  NC  accom¬ 
plishes  these  changes  in  state.  Subsequent  chapters  will 
explore  these  details,  and  Appendix  B  examines  the  details 
in  full. 


3.  Error  Conditions  and  Handling 

To  exhaustively  catalog  the  various  probable  errors 
is  beyond  the  scope  of  this  thesis  and  the  level  of  design 
at  this  stage  of  the  project;  however,  a  general  description 
of  errors  and  error  handling  is  provided  for  NC  users. 

Most  errors  fall  into  one  of  two  general 
categcries--fatal  and  non-fatal. 
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Fatal  Errors 
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These  errors  characterize  a  state  where  no 

further  useful  processing  can  be  dona.  One  should  put  this 

notion  in  the  context  of  each  individual  user  session 
instead  of  a  fatal  error  to  the  entire  processor.  For  the 

former,  specific  actions  may  be  taken  upon  recognizing  the 

error,  and  the  session  will  be  ABORTed.  For  the  latter,  one 
may  visualize  that  Recovery  Mangement  would  have  deadlock 
detection  facilities  and  would  initiate  actions  to  reboot 
the  erroneous  processor.  Locally-generated  errors  that  are 
not  detected  or  corrected  by  LC  or  MS  will  be  fatal  errors 
(if  detected)  to  NC.  NC  is  also  not  very  tolerant  of  errors 
detected  from  the  TCE  interface.  The  fundamental  action  for 
such  errors  is  to  inform  the  user  of  the  error,  report  the 
_rror  to  Recovery  Management  and  ABORT  the  session. 

b.  Non-Fatal  Errors 

These  errors  are  ones  from  which  recovery  is 
very  likely.  Such  is  the  case  when  LC  does  not  get  an 
initial  acknowledgement  on  a  message  sent,  MS  receives  a 
duplicate  copy  of  a  message,  or  Buffer  Manager  runs  out  of 
dedicated  buffer  space.  The  processing  situation  has 
degraded,  but  may  be  continued.  For  NC,  almost  all  locally- 
generated  errors  should  be  detected  by  its  LC  or  MS  modules. 
Furthermore,  NC  has  virtually  no  capability  to  deal  with 
such  errcrs  except  tc  treat  them  as  fatal  and  sequence 
through  the  ABORT  outlined  previously;  however,  on  the  ether 
side  of  the  NC  gateway,  NC  does  have  a  limited  capability  to 
deal  with  one  TCE  error;  "Insufficient  Resources" 
[Ref.  6, pp. 54-58  ].  For  this  condition,  NC  can  attempt,  at 
least  twe  mere  times,  to  re-invoke  TCP.  If  those  attempts 
are  unsuccessful,  the  error  becomes  fatal  and  NC  initiates 
an  AECRT  for  the  session. 
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III.  NATIONAL  COMMUNICATIONS  MODULE  DESIGN 

A.  INTRODUCTION  AND  DESIGN  METHODOLOGY 

This  chapter  will  examine  the  major  design  decisions 
that  were  made  while  deriving  the  National  Communications 
(NC)  module.  Several  design  decisions  were  first  required  to 
build  a  detailed  concept  of  operation  of  the  LAN,  and  these 
decisions  formed  a  basis  for  determining  how  NC  should  be 
constructed  to  interface  with  the  LAN.  Similarly,  a  concise 
determination  of  how  TCP  functioned  was  needed  before  NC 
could  be  designed  to  access  and  be  accessed  by  the  DDN . 
Indeed,  the  NC  design  is  largely  shaped  by  the  nature  of  its 
inputs  and  outputs  because  these  must  dovetail  with  both 
SPLICE  and  EDN  design  specifications. 

The  design  methodology  employed  for  this  task  was  based 
on  a  structured  analysis  approach.  The  primary  design  aid 
utilized  for  this  methodology  was  HIPO,  which  stands  for 
Hierarchy,  plus  Input,  Process,  Output  [Ref.  9].  HIPO  had 
previously  been  used  for  the  SPLICE  project,  [Ref.  10]  and 
[Ref.  11],  and  provides  a  flexible  medium  for  expressing 
sequential  designs  for  input  and  output  oriented  systems. 
Detailed  HIPO  diagrams  are  provided  in  Appendix  A.  The 
underlying  basis  of  the  HIPO  technique  was  functional  decom¬ 
position  in  a  top-down  approach.  Also,  seme  Information 
Hiding  design  concepts,  [Ref.  12]  and  (Ref.  13],  were  used, 
as  appropriate.  These  concepts  are  particularly  desirable 
when  one  considers  the  need  for  SPLICE  modules  to  be  easy  to 
modify.  Changes  to  SELICE  operations  such  as  message  format 
modification  are  likely  to  occur  over  time.  Effective  modu¬ 
larization  in  the  design  phase  will  minimize  the  impact 
later  on  for  such  changes.  This  was  one  of  the  reasons,  for 
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example,  a  new  server  process  known  as  Message  Server  was 
abstracted  cut  of  the  design  of  the  LAN. 

One  of  the  other  products  of  the  NC  design  effort  was 
the  development  cf  pseudo  code  (Appendix  B)  .  Additionally, 
an  attempt  was  made  to  place  the  sequential  HIPO  design  into 
a  concurrent  and  multi-tasking  environment  by  using  the 
programming  language  Ada  (Appendix  C)  as  a  Systems  Design 
Language  (SDL)  .  HIPC  charts,  pseudo  code  and  the  Ada  SDL 
were  the  end  products  of  the  design.  The  rest  cf  this 
chapter  will  highlight  the  key  design  decisions  that  were 
made  in  the  process  cf  developing  those  products. 

B.  LAN  FUNCTIONAL  BECUIREM ENTS  IflPOSED  UPON  NC 

1  •  Interactive  vs.  Def erred  Message  Traffic 

Cne  of  the  basic  assumptions  made  about  SPLICE  is 
that  there  will  be  both  interactive  and  non- interactive 
(deferred)  message  traffic  present  in  the  network  (see 
chapter  1)  .  It  is  logical  to  assume  that  users  will  some¬ 
times  want  to  get  a  response  right  away,  whereas,  ether 
times,  they  will  have  neither  the  time  nor  the  inclination 
to  wait  for  the  answer. 

An  example  of  an  interactive  session  is  one  in  which 
a  terminal  user  calls  up  the  Database  Management  (DEM) 
module  to  find  out  the  current  status  of  a  stock  item.  The 
message  is  sent  to  DEM,  which  responds  quickly  by  sending  a 
message  containing  the  information  requested  to  Terminal 
Management  (TM) .  TM  then  presents  it  to  the  user  in  the 
proper  screen  format. 

Examples  of  deferred  sessions  include  those  in  which 
a  terminal  user  has  a  large  number  of  transactions  to  be 
processed  in  a  batch  mode  by  one  of  the  functional  modules 
or  by  the  background  host  processor.  He  might  also  want  to 
send  some  "mail"  to  another  terminal  user,  requesting  his 
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assistance  cn-  a  problem.  In  these  deferred  examples,  the 
users  dc  net  need  instant  response--an  answer  in  several 
hours  is  probably  sufficient.  In  the  case  of  database 
updates,  a  response  may  not  be  required  at  all. 

One  way  to  handle  interactive  and  deferred  traffic 
is  to  require  no  distinction  between  them.  Each  message  of 
a  certain  precedence  is  put  onto  the  a  single  queue  of  that 
precedence,  regardless  of  its  session  type  (deferred  or 
interactive) .  Consider,  however,  the  case  when  a  user 
releases  a  large  Routine  deferred  message  of  several  hundred 
transactions  just  prior  to  another  user  attempting  tc  send  a 
short  routine  interactive  message.  The  response  time  for 
the  interactive  user  would  degrade  to  a  point  where  he  might 
wait  several  minutes  before  he  gets  any  response  at  all. 
Opening  a  session  is  even  more  critical,  especially  when  the 
traffic  volume  is  heavy  and  there  are  few  resources  left  for 
creating  local  connections  on  the  DON.  An  interactive 
session  clearly  should  get  priority  over  any  deferred 
session. 

a.  Interactive  First,  Deferred  Second 

With  both  interactive  and  deferred  traffic 
competing  fer  resources,  it  becomes  necessary  that  the  two 
be  kept  separate.  Interactive  messages  should  gex  quick 
response,  whereas  deferred  traffic  can  wait. 

Two  sets  of  message  queues  have  been  developed 
within  NC  and  the  Message  Servers.  These  queues  handle  the 
interactive  vs.  deferred  distinction.  A  session  will  be  set 
up  as  either  deferred  or  inxeractive  with  a  certain  prece¬ 
dence.  If  the  session  happens  to  be  deferred  with  a  routine 
precedence,  all  its  messages  will  go  to  the  deferred  routine 
queue.  All  interactive  routine  messages  will  get  serviced 
from  their  queue  before  any  deferred  routine  messages,  since 
the  interactive  and  deferred  routine  prcedence  queues  are 
completely  separate. 


t.  Direction  cf  Message  Flow 


Another  distinction  between  interactive  and 
deferred  sessions  is  the  direction  of  the  message  flow. 
While  interactive  flew  will  be  bidirectional,  deferred  will 
be  unidirectional  only.  This  difference  is  somewhat  blurred 
with  messages  sent  over  the  DDN.  In  the  DDN ,  TCP  sets  up  a 
full  duplex  connection  with  all  virtual  circuits,  and  it 
would  be  easy  to  begin  sending  messages  for  both  types  of 
sessions  as  soon  as  the  local  connection  was  established. 
This  can  be  done  even  before  the  destination  functional 
module  has  been  informed  that  there  will  be  incoming 
messages  for  it.  The  messages  would  simply  arrive  at  the 
remote  LAN's  NC  and  be  sent  out  over  the  LAN  bus  with  the 
destination's  address  on  them.  Consider,  however,  the  case 
where  the  destination  process  is  initially  unable  to  respond 
to  the  interactive  messages  for  one  reason  or  another.  The 
source  module  must  take  the  time  to  send  three  transmissions 
of  the  same  message  before  it  knows  it  can  abort  the 
session.  The  source  process  should  not  have  zo  wait  for  the 
message  timeout  and  retransmission  cycle  (which  could  take 
several  minutes) ,  to  find  out  that  it  will  not  be  able  to 
open  a  session. 

To  eliminate  the  possibility  cf  opening  an 
interactive  session  when  the  destination  is  unreachable, 
there  will  be  an  end-to-end  acknowledgement  during  the 
session  open  phase.  In  other  words,  before  any  session 
messages  can  be  sent,  both  local  and  remote  modules  must  be 
ready  to  receive. 

On  the  ether  hand,  deferred  traffic  does  not 
need  this  handshaking.  Traffic  is  only  one  way  and  there  is 
also  a  capability  to  deposit  incoming  deferred  traffic  in  an 
inactive  process's  mailbox  until  he  becomes  active  again. 
This  mailbox  capability  will  be  discussed  in  more  detail 
under  the  Message  Server. 


NC,  like  tie  other  functional  modules,  must  take 
several  actions  each  time  it  sends  or  receives  a  message. 
One  way  to  handle  these  message  functions  is  to  imbed  them 
in  each  of  the  functional  modules.  This  might  be  a  viable 
alternative  in  the  future;  however,  there  are  two  main 
reasons  that  these  functions  have  been  kept  separate  during 
the  current  design  of  NC.  First,  these  actions  are  common 
to  all  the  functional  modules,  and  NC  is  the  first  func¬ 
tional  module  to  reach  the  formal  design  phase.  Keeping  the 
message  functions  separate  will  facilitate  the  design  of 
other  functional  modules,  since  zhe  message  handling  func¬ 
tions  need  only  be  developed  once.  Second,  these  actions 
depend  a  great  deal  cn  the  specific  hardware  or  operating 
system  of  the  processor  on  which  the  functional  module  is 
running.  Keeping  the  message  functions  separate  allows  high 
level  interfaces  to  be  built  now,  while  deferring  the  devel¬ 
opment  of  the  physical  interfaces  until  the  implementation 
phase . 

The  above  reasoning  led  to  the  development  of  the 
server  process  called  the  Message  Server.  It  is  recognized 
that  the  actual  SPLICE  LAN  provided  by  the  vendor  might 
implement  many  of  the  Message  Server's  functions.  If  this 
occurs,  the  previously  defined  interfaces  of  the  Message 
Server  can  be  mapped  directly  to  those  of  the  vendor's 
network. 

The  ether  server  processes  that  have  been  defined 
are  Local  Communications  and  Buffer  Manager.  All  three 
server  processes  have  been  described  in  Chapter  2. 

Begardless  of  their  eventual  implementation.  Message 
Server,  Euffer  Manager  and  Local  Com m unications  act  as  lower 
level  servers  for  the  functional  modules,  relieving  them  of 
the  more  mundane  and  trivial  matters  of  message  traffic. 


Since  messages  being  bandied  by  these  server  processes  must 
be  passed  tc  each  of  them  in  turn,  at  least  one  copy  of  the 
processes  will  exist  in  every  physical  processor.  This  way 
they  can  all  work  on  the  same  message  by  simply  passing  the 
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Figure  3.1  Functional  Module  and  Server  Process  Hierarchy 


address  of  the  message  buffer  among  them.  Figure  3.1  shews 
the  relationship  among  these  server  processes  and  the  func¬ 
tional  modules  located  within  the  same  processor. 

a.  Local  Communications  (LC) 

LC  was  shown  as  a  functional  module  in 
[Ref.  1rf.11]  because  the  level  of  design  at  that  time  was 
such  that  the  actual  implementation  of  LC  need  not  be 
considered.  It  is  new  felt  that  LC  will  be  the  collection 
of  lower  level  protocols  provided  by  the  eventual  vender  of 


the  SELICE  local  area  network.  These  protocols  might  even 
be  provided  on  a  separate  microprocessor  board  within  each 
processor.  This  makes  any  interface  to  LC  very  system 
dependent  and  subject  to  change.  Therefore,  Message  Server 
will  provide  the'  interfaces  necessary  to  LC,  keeping  the 
functional  modules  separated  from  implementation  dependent 
functions. 

b.  Message  Server  (MS) 

(1 )  .  Mailbox  Manager . 

An  assumption  made  in  [Hef.  1,p.41]  is 
that  the  SPLICE  LAN  will  have  a  mailbox  capability.  That 
is,  fcr  any  deferred  session,  the  message  can  be  deposited 
into  a  mailbox  and  a  session  will  be  initiated  with  the 
mailbcx  as  the  source  (and  later  the  destination).  To 

support  this  function,  an  MS  will  have  the  capability  of 
managing  tne  mailboxes  fcr  its  functional  module.  It  is 
important  tc  point  out  that  the  absence  of  mailboxes  in  the 
LAN  would  result  in  the  inability  to  send  anything  but 
interactive  traffic,  since  there  would  be  nowhere  to  store 
messages  for  inactive  processes.  There  will  also  be  times 
when  a  destination  is  unreachable  for  one  reason  or  another. 
If  SS  detects  this  during  the  open  phase  of  a  session,  the 
session  should  net  be  allowed  to  continue.  If  the  session 
is  a  deferred  one,  there  is  no  reason  why  the  user  must  be 
the  one  tc  retry  later,  when  MS  could  do  it  for  him. 
Suppose  however  that  SS  doesn't  know  that  the  destination  is 
unreachable  and  opens  the  deferred  session.  The  message  is 
sent  to  the  destination,  but  the  destination  MS  need  not 
throw  the  message  out,  it  can  deposit  the  message  in  the 
process  mailbox  and  cause  the  process  to  be  notified  of  mail 
when  it  is  reachable  again. 


(2)  .  Sessio n  Timeout. 

Suppose  in  another  case,  an  interactive 
sessicn  has  been  in  existance  for  several  minutes  without 
any  message  traffic.  The  session  is  tying  up  resources  that 
might  be  needed  for  ether  new  or  more  active  sessions.  To 
help  alleviate  this  problem,  MS  will  contain  a  “session 
timer*1  that  will  keep  track  of  when  the  last  message  was 
sent  cr  received.  If  the  elapsed  time  exceeds  a  certain 
limit,  MS  will  issue  an  abort  and  notify  the  user  of  the 
action. 

(3)  .  Session  I ndeoendence. 

Once  a  session  is  set  up,  there  is  no  need 
for  Sessicn  Services  to  get  involved  until  the  sessicn  is 
closed  cr  aborted.  For  this  reason,  SS  will  pass  all  the 
vital  information  to  MS  at  the  beginning  of  the  session,  so 
that  SS  can  drop  out  of  the  picture  and  let  MS  do  all  the 
work  until  the  sessicn  ends. 

c.  Buffer  Manager  <BM) 

Since  [  Eef .  1,p.14]  requires  that  each  func¬ 
tional  module  have  enough  dedicated  memory  to  handle  at 
least  one  incoming  message,  it  is  important  for  NC  tc  know 
how  message  buffers  will  be  allocated.  Since  the  physical 
processors  for  SPLICE  have  not  even  been  defined  yet,  it  is 
net  known  how  the  future  processors  will  handle  memory  allo¬ 
cation.  Therefore,  Buffer  Manager  was  developed  as  a 
logical  abstraction  cf  the  buffer  allocation  process,  so 
that  the  functional  modules  can  be  designed  ccnsistantly, 
even  with  underlying  hardware  unknowns  or  later  changes. 


Session  Services  Module 


Session  States 


All  modules,  including  NC,  use  Session  Services 
(SS)  each  time  a  session  is  opened  or  closed.  NC  and  SS 

must  communicate  with  each  other  in  order  to  set  up  a 
session.  This  communication  requires  that  NC  and  SS  go 
through  a  series  of  states  in  order  to  control  the  session 
traffic.  This  progression  from  state  to  state  insures  that 
no  message  traffic  is  sent  before  the  proper  LAN  or  DDN 
connections  have  been  made. 

t.  Fixed  Location 

It  should  be  emphasized  that  SS  is  the  central 
distributer  of  addresses  for  all  other  functional  modules  in 
the  SELICE  Network.  Eecause  of  this,  all  other  modules  must 
know  how  to  get  to  SS  in  order  to  set  up  a  session.  Since 
message  traffic  to  SS  will  be  handled  just  as  any  other 
traffic,  all  functional  modules  must  know  the  logical  and 
physical  addresses  of  SS.  This  requires  that  SS  cannct  be 
physically  mcved  without  modifying  its  address  in  all  func¬ 
tional  modules  that  will  want  to  send  messages  to  it. 

c.  Session  Number 

Session  numbers  are  given  out  by  SS  in  order  to 
identify  the  messages  for  that  session.  These  session 
numbers  are  unique  within  each  LAN  only.  There  is  the 
provision  for  one  functional  module  to  have  several  sessions 
in  operation  at  cne  time  [Ref.  1,pp.  42-43  ].  There  is  also 
the  possibility  that  some  of  these  sessions  are  with  local 
modules  and  some  are  with  remote  modules.  It  is  reasonable 
to  expect  that  two  functional  modules  will  have  multiple 
sessions  between  them  (TM  and  D3M  are  likely  candidates)  . 
Unique  message  numbers  are  assigned  in  each  LAN,  but  there 


is  no  guarantee  that  a  message  coming  from  a  remote  LAN  will 
have  a  message  number  unique  to  the  destination  LAN. 
Therefore,  there  must  be  a  method  by  which  these  modules  can 
uniquely  identify  incoming  messages  and  acknowledgements. 
One  method  would  be  to  have  NC  keep  a  table  of  the  message 
numbers  and  to  which  session  each  number  maps.  This  method 
would  create  a  lot  of  unnecessary  overhead  and  might  not  be 
possible  when  several  different  LANs  are  communicating  with 
each  ether.  The  best  solution  is  the  addition  of  a  session 
number  field  to  the  SPLICE  message  and  acknowledgement 
formats  (see  Figure  2.1).  With  the  session  number  in  place 
in  every  message,  it  becomes  an  easy  task  for  NC  to  map 
between  session  number  and  local  connection  name  for  every 
message  it  handles.  For  outgoing  messages,  NC  merely  dees  a 
table  lcck-up  with  the  local  session  number  as  the  key  and 
then  invokes  TCP  with  the  Local  Connection  Name  corres¬ 
ponding  tc  that  session  number.  For  incoming  messages,  TCP 
will  always  return  tc  NC  with  the  Local  Connection  Name  as  a 
parameter,  thus  allowing  NC  to  map  to  the  local  session 
number.  See  Figure  3.3  for  a  representation  of  NC's  session 
table. 


4 .  Network  Services  Pi  rectory 

The  Network  Monitoring  Center  will  continually  send 
updates  concerning  LAN  and  functional  module  status  tc  each 
LAN's  Recovery  Management  module  [Ref.  1,p.28]«  RM,  in 
turn,  will  update  the  Network  Services  Directory  (NSD)  .  The 
fields  in  the  NSD  [Ref.  1,p.40]  consists  of  only  services 
codas  and  addresses,  but  no  status  information.  Adding 
status  information  enables  SS  to  determine  whether  a  desti¬ 
nation  is  reachable  during  the  opened  phase  of  a  session. 
This  greatly  reduces  the  time  involved  in  determining 
whether  ac  interactive  session  can  be  opened  or  not.  It 
also  gives  the  capability  of  developing  an  online  query 


function  that  would  inforn  the  user  of  reachable  destina¬ 


tions.  The  function,  which  might  be  called  •'STATUS",  could 
inform  the  requester  of  which  entities  within  the  NS C  are 
reachable . 

5 •  Recovery  Management 

Network  statistics  are  a  vital  part  of  monitoring 
the  capacity  of  a  network.  Along  with  the  continual  network 
updates,  the  SPLICE  Network  Monitoring  Center  will  likely  be 
requesting  periodic  feedback  about  the  LAN  from  Recovery 
Management  (RM)  .  Since  RM  will  be  reporting  the  LAN  statis¬ 
tics,  '  it  is  logical  that  RM  also  contain  the  process  that 
gathers  these  statistics. 

C.  DEN-RELATED  DESIGN  ISSUES 

1  •  Implications  of  Current  SPLICE  Design 

As  briefly  addressed  in  Chapter  1,  a  number  of 
design  decisions  were  made  for  the  SPLICE  project  pricr  to 
the  NC  design  effort  that  had  bread  implications  for  the  NC 
module.  These  will  be  addressed  first  to  provide  a  backdrop 
for  decisions  made  during  the  course  of  the  NC  design. 

a.  NC  as  a  CEN  Gateway 

One  of  the  general  ways  of  examining  the  NC 
module  is  tc  look  at  how  it  serves  as  a  DDN  gateway  module. 
To  use  the  term  "gateway"  is  not  consistent  with  AREANET 
notion  cf  a  gateway  (Be£.  14],  ARPANET  gateways  are 
normally  implemented  at  the  Internet  Protocol  (IP)  level.  NC 
will  be  a  TCP  level  gateway.  TCP/IP  will  be  implemented  in 
the  SPLICE  PEP,  but  not  elsewhere  within  the  LAN. 
(Ref.  1,p.18]. 

When  NC  receives  a  call  from  TCP  concerning  an 
incoming  message,  NC  must  access  the  buffer,  and  using  the 


the  LAN. 


LAN  message  format,  find  the  LAN  addressee.  Recall  that  the 
data  portion  of  the  TCP  segment  is  the  entire  LAN  message/ 
message  fragment.  When  NC  calls  upon  TCP  to  send  a  message, 
it  passes  as  a  parameter  to  TCP  the  destination  (SPLICE  PEP) 
address.  The  way  that  NC  performs  its  operations  is  impor¬ 
tant  because  it  dees  not  perform  routing  in  the  way 
performed  by  most  gateways.  NC  depends  upon  the  fact  that 
the  lccal  address  for  the  message  can  be  found  in  the 
message  buffer.  Note  that  when  TCP  passes  the  buffer 
pointer  tc  NC,  the  buffer  contains  only  the  data  that  was 
passed  to  the  source  TCP.  That  data  is  a  LAN-f ermatted 
message  sent  by  the  source  NC. 

NC's  gateway  design  will  initially  mean  that 
SPLICE  LANs  can  only  send  or  receive  messages  to  or  from 
ether  SPLICE  sites  who  utilize  the  same  message  format  and 
handling  procedures.  It  is  possible  that  message  communica¬ 
tions  with  non-SPLICE  activities  on  the  DDN  might  be  imple¬ 
mented  later.  The  major  elements  needed  for  this  type  of 
internetworking  are  standardized  message  formats  and  common 
handling  procedures  (acknowledgements,  session  practices, 
etc.).  A  DCN  standard  for  internetworking  of  LANs  utilizing 
TCP-level  gateways  might  be  developed  at  a  later  date. 
SPLICE  adoption  of  such  a  standard  could  lead  tc  greater 
intercommunication  with  non-SPLICE  communities  on  the  DON. 

b.  NC  Assembly  and  Disassembly  of  Messages 

Any  given  NC  module  will  only  receive  messages 
from  ether  SPLICE  LANs,  and  the  message  format  and  maximum 
message  or  message  fragment  size  will  be  common  to  all  LANs. 
TCP  is  assumed  to  be  capable  of  accepting  an  outgoing 
message  (buffer)  for  a  maximum  size  SPLICE  message  or 
message  fragment.  TCP  will  disassemble  the  LAN  message  into 
TCP  segments  before  sending  it  onto  IP  for  datagram  service 
to  the  destination.  At  the  destination,  TCP  reassembles  the 


LAN  message  putting  it  back  into  the  exact  format  that  the 
source  TCP  received  from  the  source  NC.  Therefore,  NC  will 
have  nc  requirement  to  disassemble  or  assemble  outgoing  or 
incoming  messages.  as  described  in  the  last  chapter,  NC 
must,  however,  sequence  the  messages  using  the  stop  and  wait 
ackncwlagement  scheme. 

D.  DOB  FOHCTXONAL  RETIREMENTS  IMPOSED  UPON  NC 
1  •  Precedence  and  Security 

a  basic  DDN  subnet  requirement  is  that 

"...there  be  reliable  mechanisms  for  assigning  network 
resources  for  different  user  priority  levels  such  that 
the  higher  priority  users  are  assignee  the  use  of  scarce 
resources  ahead  of  lower  priority  users." 

CRef.  4,p.  102  ] 

The  precedence  mechanisms  throughout  the  DDN  depend 
upon  the  correct  information  in  the  precedence  field  of  the 
IP  header  cn  DDN  messages  [Ref.  15, pi  12],  Precedence  infor¬ 
mation  is  given  to  IP  by  TCP,  and  TCP  will  use  default 
values  if  precedence  is  not  specified  by  NC.  Similarly,  the 
DDN  must  be  capable  cf  handling  massages  of  different  clas¬ 
sifications  and  does  so,  in  part,  through  the  use  of  a  clas¬ 
sification  fiald  in  the  message  header  at  both  the  TCP  and 
IP  level.  TCP  will  use  default  values  for  classification  if 
not  provided  by  NC. 

There  are  basically  three  alternatives: 

•  Dc  net  implement  classification  or  precedence  capabili¬ 
ties  internal  to  the  SPLICE  LAN. 

•  Implement  both  classification  and  precedence  handling 
in  SPLICE. 

•  Implement  either  classification  or  precedence  handling. 

If  SPLICE  choosas  net  to  implement  all  of  its  DDN 
message  traffic  will  traverse  the  DDN  backbone  with  the 
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lowest  precedence:  EOOTINE .  This  would  be  highly  undesi¬ 
rable  during  wartime  conditions  when  supply  actions  such  as 
emergency  requisitions  may  fully  justify  higher  precedences 
including  FLASH.  It  is  essential  that  SPLICE  LANs  have  the 
capability  to  utilize  the  precedence  mechanisms  of  the  DDN. 
With  regard  to  security,  it  is  true  there  is  no  present  need 
for  a  classification  field  on  the  LAN  message  format; 
however,  if  the  need  later  evolves  for  SPLICE,  and  classi¬ 
fied  systems  are  added,  then  changes  would  have  to  be  imple¬ 
mented  tc  support  a  new  message  format.  Implementation  at  a 
later  (operational)  stage  of  SPLICE  would  be  far  costlier 
than  providing  for  that  classification  capability  now.  The 
addition  of  two  extra  fields  to  the  message  format  will 
result  in  negligible  overhead  to  SPLICE.  Recall  that  a  user 
will  establish  his  precedence  and  security  levels  at  the 
outset  of  a  session,  and  these  remain  fixed  throughout  a 
given  session.  Default  values  can  be  used  for  most  sessions. 

Classif icaticn  and  precedence  fields  will  be  added 
to  the  SPLICE  message  format.  Procedures  to  support  proper 
handling  of  classification  and  precedence  will  be  integrated 
into  all  applicable  SELICE  modules. 

2.  TCP  ST  AT  PS  Command 

The  TCP  command  named  STATUS  provides  status  infor¬ 
mation  on  the  particular  local  connection  requested 
tBe£.  6,p.49].  This  is  an  optional  command  which  means  its 
implementation  is  not  required  by  the  vendor  implementing 
TCP.  The  information  returned  from  TCP  may  include  the  items 
shown  in  Figure  3.2. 

With  regard  to  NC,  a  decision  must  be  made  about 
whether  to  implement  routines  to  utilize  the  TCP  STATOS 
command.  If  NC  does  provide  the  routines  to  utilize  the 
STATOS  command,  and  the  vendor  does  not  implement  them  in 
TCP.  the  routines  wculd  have  to  be  modified  to  avcid  a  TCP 


Local  Socket 
Foreign  socket 
Lccal  Connection  Name 
Receive  Window 
Send  Window 
Connection  state 

Number  cf  Buffers  Awaiting  Acknowledgement 
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Pr  ecedence 

Securit  y/Compartment 
Transmission  Timeout 


[Bef.  6,  pp.  49-50  ] 


Figure  3.2  Information  Returned  by  TCP  STATUS  Command. 

error.  If  the  vendor  implements  and  NC  provides  access,  then 
an  additional  amount  of  overhead  is  levied  on  NC  and  TCP 
every  time  the  command  is  utilized.  On  the  other  hand,  if  NC 
does  not  inplement  tut  the  TCP  vendor  does,  the  user  will 
not  have  the  benefit  cf  the  information.  Also,  there  is  the 
advantage  of  no  additional  overhead  induced  on  NC  or  TCP  if 
the  command  is  net  supported. 

Cne  may  also  argue  how  useful  the  STATUS  information 
is  tc  the  normal  SPLICE  user.  While  the  information  may  be 
useful  for  debugging  purposes  or  for  personnel  maintaining 
the  computer  system.  Almost  all  of  the  data  shown  in  Figure 
3.2  will  net  be  wanted  by  the  typical  SPLICE  user.  More 
often,  a  user  will  te  interested  in  whether  a  particular 
destination  is  "up"  or  reachable  via  SPLICE.  As  discussed 
earlier,  a  query  capability  should  be  added  to  Session 
Services  sc  that  users  can  check  the  Network  Services 
Directory  (NSD)  for  user  information.  Similarly,  a  user  may 
query  to  obtain  information  about  his  particular  session. 
Such  a  query  capability  would  not  detract  from  the  perfor¬ 
mance  cf  TCP  or  NC. 


NC  will  not  implement  the  routines  to  utilize  the 
optional  TCP  STATUS  command. 

3.  Message  Retransmission  by  NC 

The  SPLICE  design  requires  NC  to  employ  a  stop  and 
wait  acknowledgement  scheme.  Under  this  method  NC  sends,  via 
TCP,  each  outgoing  message  or  message  fragment  and  waits  for 
an  acknowledgement  before  sending  the  next  message  in 
sequence.  Underneath  NC,  TCP  has  taken  the  message  provided 
by  NC  and  attempts  to  send  it  to  the  destination  TCP.  The 
source  TCP  employs  a  retransmission  scheme  and  will  continue 
to  retransmit,  periodically,  the  NC  message  until  a  destina¬ 
tion  TCP  acknowledgement  is  received,  or  the  time  tc  live, 
associated  with  the  message,  expires.  The  stop  and  wait 
acknowledgement  scheme  [Ref.  1,p.34],  did  not  specifically 
require  NC  to  perform  retransmissions. 

A  decision  must  be  made  whether  NC  should  implement 
the  routines  to  perfcrm  retransmissions.  If  NC  performs 
retransmissions,  it  will  effectively  be  duplicating  the  work 
cf  TCP,  will  be  a  source  of  duplicates,  and  will  also  tend 
to  slew  TCP  down.  Assuming  that  TCP  is  operable,  TCP  will  be 
performing  retransmissions  on  a  specific  message  at  the  same 
time  that  NC  would  request  TC?  to  send  the  same  message 
again.  If  TCP  cannot  get  an  acknowledgement  from  the  desti¬ 
nation  TCP,  then  it  is  not  possible  that  NC  can  get  an 
acknowledgement  from  the  destination  NC.  The  connection 
should  be  abandoned  and  the  destination  assumed  to  be  in  an 
erroneous  state.  If,  in  fact,  the  source  TCP  is  not  properly 
functioning,  then  NC  should  ABORT  anyway  and  not  attempt  any 
retransmission.  In  general,  retransmission  should  net  be 
performed  at  multiple  levels.  Analogously,  NC  or  MS  should 
not  perfcrm  retransmissions  within  the  LAN  if  LC  routinely 
performs  retransmissions. 


NC  will  cot  perform  retransmission  of  a  message  when 
no  acknowledgement  is  received. 

4.  TCP  Para  meters:  URGENT,  Ootio  ns 

The  TCP  specification  requires  the  implementation  of 
TCP  routines  to  support  the  "Options''  and  the  ''URGENT'' 
parameters  that  may  be  optionally  used  by  NC  when  invoking 
TCP  with  CPEN  or  SEND  commands.  The  URGENT  parameter  is  used 

"...tc  stimulate  the  receiver  to  process  the  urgent  data 
and  to  indicate  to  the  receiver  when  all  currently  kncwn 
data  has  teen  received."  [Ref.  6,p.41] 

Thus,  the  URGENT  contruct  allows  the  user  to  send  data  of  a 
more  "urgent"  nature  in  the  "middle"  of  a  data  stream  or 
session  cf  ncn-urgent  data.  This  may  be  very  important  for 
real-time  system  users  of  the  DON ,  but  no  such  need  is 
dictated  by  the  SPLICE  requirements.  The  "Options"  parameter 
currently  allows  three  alternative  uses:  End  of  Option  List, 
No-Operation  and  Maximum  Segment  Size  [Ref.  6,p.18].  The 
use  cf  the  parameter  is  optional,  and  is  not  needed  for  any 
known  SPLICE  requirement. 

E.  SUBMODULES  OF  THE  NATIONAL  COMMUNICATIONS  MODULE 

This  section  serves  as  a  summary  of  the  previously 
discussed  design  decisions  as  they  have  been  integrated  into 
the  NC  mcdule. 

1  •  General  Structure 

The  general  structure  of  the  NC  submodules  was 
largely  determined  by  two  factors.  First,  the  assumption 
that  SPLICE  will  provide  for  interactive  and  deferred 
traffic,  and  second,  that  TCP  progresses  through  various 
states  as  it  processes  messages  through  the  DDN. 


The  differences  between  interactive  and  aef erred 
message  traffic  have  been  discussed  earlier,  and  will  net  be 
dealt  with  again  here.  It  is  sufficient  to  say  that  these 
differences  creare  a  natural  division  of  functions  by  which 
part  of  the  structure  of  the  NC  submodules  has  been  deter¬ 
mined. 

The  details  of  the  TCP  states  have  also  been 
discussed  previously.  The  TCP  states  provide  a  framework 
for  further  division  of  the  deferred  and  interactive 
portions.  Since  NC  must  deal  with  the  TCP  states,  NC  was 
designed  to  deal  with  only  one  state  at  a  time.  This  way, 
the  states  cf  TCP  are  controlled  by  the  states  of  NC  (see 
Figure  2.3). 

2 *  Data  S tructures 

Two  general  data  structures  emerged  during  the  NC 
design.  The  first  is  the  queue.  There  are  three  separate 
sets  of  queues  used  in  the  NC  submodules.  &  graphic  illus¬ 
tration  cf  these  queues  can  be  found  in  Appendix  C,  figure 

C.  1. 

The  first  set  of  queues  consists  of  one  queue  for 
each  open  session.  This  is  a  result  of  the  required  NC  to 
NC  acknowledgement  fer  each  session.  NC  must  queue  up  any 
waiting  messages  in  a  certain  session  until  an  acknowledge¬ 
ment  is  received  from  the  remote  NC  for  a  previously  trans¬ 
mitted  message  in  that  session.  This  first  set  of  queues 
funnels  messages  to  the  other  two  sets,  never  allowing  more 
than  one  unacknowledged  message  per  session  at  any  given 
time.  Cf  course,  there  may  be  many  unacknowledged  messages 
between  any  given  pair  of  NCs,  but  only  one  per  session. 
This  provision  imposes  no  restriction  on  the  possibility  of 
having  multiple  sessions  outstanding  between  a  pair  of  func¬ 
tional  modules. 


The  other  two  sets  of  queues  enforce  precedence  —  one 
set  is  for  interactive  messages,  the  other  for  deferred 
messages.  These  queues  are  necessary  because  of  the 
distinction  between  interactive  and  deferred  sessions.  The 
precedence  queues  insure  that  the  session  message  with  the 
highest  priority  is  given  to  TCP  first — with  the  interactive 
messages  given  a  higher  priority  than  deferred  messages  of 
the  same  precedence.  TCP  has  mechanisms  to  handle  prece¬ 
dence,  but  does  net  distinguish  between  interactive  and 
deferred  sessions. 

NC  does  not  gueue  any  messages  sent  through  Message 
Server,  since  MS  already  has  precedence  queues  in  it. 

The  second  data  structure  present  is  the  session 
table.  Its  structure  is  shown  in  Pigure  3.3.  The  session 
number  ard  lccal  connection  name  entries  are  used  to  map  the 
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Pigure  3.3  National  Communications  Session  Table. 

messages  tc  their  proper  destinations.  The  remote 
address  is  necessary  for  opening  and  closing  a  session, 
the  two  NC's  will  be  communicating  directly. 

3*  General  Functional  Flow 

In  summary,  there  are  essentially  three  factcrs 
determine  hew  a  message  is  treated  by  NC. 


1.  Whether  the  message  is  incoming  from  or  outgoing  to 
the  DDN. 

2.  Whether  the  message  is  interactive  or  deferred. 

3.  The  particular  state  in  which  the  session  is  oper¬ 
ating. 

These  three  factors  are  well  pronounced  in  the  algorithmic 
description  of  NC  (Appendix  C)  .  The  main  module  of  NC 

(NC_M  AIN)  examines  the  messages  coming  from  Message  Server 

or  TCP  and  determines  which  submodule  to  call.  When  the 
proper  sufcmcdule  is  called,  it  will  use  the  sessicr.  number 
or  LC  Name  on  the  message  to  map  it  to  the  proper  destina¬ 
tion.  The  submodules  themselves  handle  NC-NC  level  acknowl¬ 
edgements. 

The  Error-Handler  is  invoked  when  TCP  errors  are 
passed  to  NC.  Almost  all  TCP  errors  will  result  in  the 

session  being  aborted  and  the  user  notified  as  such. 

Detection  cf  any  LAN  errors  will  be  the  responsibility  of 
the  Message  Server. 


IV.  NC  IMPLEMENTATION  ISSOES 

The  present  NC  design  has  been  detailed  to  the  level  of 
a  bread  algorithm,  and  should  provide  an  implementor  with  a 
general  "blueprint"  for  an  executable  process  or  series  of 
processes.  This  chapter  is  meant  to  express  some  issues  that 
will  need  to  be  resolved  or  dealt  with  to  fulfill  the 
design.  Indeed,  the  resolution  of  some  of  these  issues  may 
require  a  careful  restructuring  of  the  design. 

A.  &  MULTITASKING  -ENVIRONMENT 

The  present  design  has  primarily  dealt  with  a  sequential 
model  of  the  execution  of  NC.  As  discussed  in  Appendix  E  and 
elsewhere,  it  is  believed  that  the  design  structure  can  be 
mapped  into  various  structures  that  support  multitasking. 
Given  the  stop-and-wait  acknowledgement  scheme,  the  handling 
of  precedence  and  the  time  delays  associated  with  DDN 
traffic,  NC  should  be  heavily  oriented  towards  concurrency 
mechanisms.  Far  greater  message  processing  efficiency  may  be 
obtained  if  NC  services  or  multiplexes  several  sessions 
concurrently. 

As  detailed  in  [Ref.  7],  obtaining  protocol  efficiency 
may  also  require  an  implementation  to  rely  heavily  on  the 
FEP  operating  system;  however,  this  may  not  be  desirable 
from  a  software  maintenance  standpoint,  as  changes  or  new 
versions  of  the  operating  system  may  require  modification  of 
NC. 

Another  consideration  involves  how  TCP/IP  will  be 
supported.  As  will  be  addressed  shortly,  TCP/IP  may  be 
implemented  on  an  "outboard"  microprocessor.  An  outboard 
microprocessor  is  a  dedicated  microprocessor  executing 


TCP/IE  that  may  be  installed  within  the  FEP  and  it  would 
probably  communicate  with  NC  via  the  internal  data  or 
control  bus  of  the  FEP.  This  may  greatly  reduce  the  DDN 
protocol  overhead  in  the  SPLICE  FEP,  and  NC  and  its  Message 
Server  could  support  an  even  higher  number  of  concurrent 
sessions.  This  may,  in  turn,  produce  a  bottleneck  for  access 
to  and  frcm  the  cutbcard  computer.  In  short,  good  perfor¬ 
mance  in  a  multitasking  environment  is  likely  tc  require 
considerable  tuning. 

B.  TCP/IP  IN  AN  OOTEOARD  COMPUTER 

As  mentioned  in  the  previous  section  and  in  Chapter  1, 
one  probable  implementation  of  TCP/IP  may  be  an  outboard 
computer  to  the  SPLICE  FEP.  Microprocessor-based  Nost  Front 
Ends  (BFE)  are  likely  to  be  commonplace  on  the  DDN  and  seme 
preliminary  work  has  already  begun  on  such  an  implementation 
by  the  Naval  Telecommunications  Automation  Support  Center 
(NA7TASC)  .  This  type  of  TCP/IP  HFE  should  of f-lcad  the 
SPLICE  FEP  and  thus  provide  more  resources  to  the  resident 
processes  of  the  FEP.  One  can  also  anticipate  the  possible 
disadvantages  of  this  approach.  The  Input/Output  ports  of 
the  FEP  can  be  potential  bottlenecks  to  the  overall 
throughput  cf  the  LAN  to  DDN  interface.  Seme  implementa¬ 
tions  may 

"...end  up  copying  the  data  because  there  is  no  shared 
memory  between  processors,  and  the  data  must  be  moved 
frcm  process  tc  process  via  a  kernel  operation.  Unless 
the  amount  of  this  activity  is  kept  strictly  under 
control,  it  will  quickly  become  the  major  performance 
bottleneck."  (Ref.  7,p.  11] 

One  final  point  is  the  requirement  to  provide  an  inter¬ 
face  between  NC  and  TCP.  Although  this  will  probably  entail 
the  use  cf  the  operating  system  (kernels)  and  the  communica¬ 
tions  bus  between  processors,  another  layer  of  interface 


routines  and  calls  will  have  to  be  built  into  N C,  the  oper¬ 
ating  system  or  another  separate  process.  Such  interfaces 
can  also  lead  to  possible  bottlenecks. 

C.  LANGUAGE  ISSUES 

As  various  SPLICE  module  designs  approach  the  point  of 
actual  implementation,  the  choice  of  imlementation  language 
must  be  carefully  made.  The  SPLICE  Request  For  Proposal 
(RFP )  allows  for  either  Pascal  or  Ada  for  the  system 
programming,  and  COBCL  for  the  applications  modules. 

For  a  number  of  reasons,  any  use  of  Ada  for  implementa¬ 
tion  in  the  near  term  is  probably  ill-advised.  The  language 
was  found  to  be  a  superior  System  Design  Language  (SDL)  ,  and 
a  number  of  government  contractors  have  already  embraced  its 
use  as  a  Programming  Design  Language  (PDL)  ;  however,  it  may 
be  a  year  or  two  until  good  production  compilers  and  ether 
essential  tools  are  available.  More  importantly,  a  let  of 
questions  concerning  Ada's  run-time  behavior  remain  unan¬ 
swered.  At  least  one  study  [Ref.  16],  has  shown  that  Ada  has 
good  potential  as  a  communication  systems  programming 
language. 

The  use  of  Fascal  is  certainly  less  risky,  but  future 
implementation  efforts  must  be  concerned  with  the  potential 
disadvantages  of  the  language.  As  stated  previously,  the 
rur-time  environment  of  SPLICE  should  support  a  high  level 
of  multitasking..  It  is  highly  desirable  that  the  version  of 
Pascal  used  contains  built-in  synchronization  primitives. 
This  would  eliminate  the  need  to  use  the  operating  system 
primitives,  and  consequently  improve  the  machine  indepen¬ 
dence  of  SPLICE  modules. 

Another  important  requirement  concerns  memory  manage¬ 
ment.  Most  Pascal  implementations  generate  a  fatal,  run¬ 
time  error  when  run-time  storage  is  exceeded.  Such  errors 


must  not  fce  fatal  in  SPLICE  and  exception  handling  routines 
will  have  to  be  implemented  in  the  code  if  not  provided  by 
the  particular  version  of  Pascal.  Finally,  selecting  a  gcod 
Pascal  implementation  must  also  entail  a  detailed  look  into 
the  programming  support  environment  usable  with  the 
language. 

D.  INCREASING  EFFICIENCY 

There  are  several  reasons  why  one  would  want  to  increase 
the  efficiency  in  message  passing.  The  reason  that  should 
be  paramount  in  the  SPLICE  effort  is  to  enable  the  interac¬ 
tive  user  to  get  the  fastest  turnaround  possible. 

It  is  recognized  that  any  interface  with  TCP  involves  a 
certain  amount  of  overhead.  In  this  regard,  NC  should  be 
made  as  optimal  as  possible.  Soma  areas  in  which  the 
current  design  might  be  improved  include  acknowledgement 
schemes,  modularity  issues  and  message  buffering. 

In  addition  to  improvements  within  NC,  there  may  be 
areas  on  the  LAN  side  in  which  a  different  approach  could 
improve  message  throughput.  Areas  of  consideration  include 
Message  Server  placement  and  the  distribution  of  Session 
Services  functions. 

E.  FCLLCB-CN  EFFORTS 

The  authors  have  attempted  to  provide  a  sound  basis  for 
future  SPLICE  efforts  at  NFS  through  this  thesis.  It  is 
recommended  that  follow-on  efforts  should  be  immediately 
focused  at  developing  the  server  processes,  initially  tack¬ 
ling  the  Message  Server.  MS  is  the  key  to  the  LAN’s  message 
traffic  and  once  developed,  will  provide  a  solid  foundation 
on  which  to  build  the  functional  modules.  Buffer  Manager 
would  probably  have  to  be  built  concurrently,  but  this  is 
considered  to  be  a  much  easier  task  than  MS. 
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Ones  HS  is  developed,  the  next  logical  step  is  to  build 
TN  and  perhaps  DBH  with  a  deferred  capability,  only.  If  the 
development  of  NC  is  completed  during  this  time  also,  the 
basic  SPLICE  Network  could  be  tested,  adding  interactive 
traffic  later. 

Ml  cf  this  developmental  effort  would  be  greatly  faci¬ 
litated  by  the  use  of  a  proper  testbed.  There  is  an  excel¬ 
lent  opportunity  fcr  the  use  of  the  VAX  configuration 
supported  by  the  Computer  Science  Department  at  NPS.  The 
department  has  recently  installed  an  Ethernet  capability 
connecting  the  VAX  machines  with  a  set  of  microprocessors. 
In  addition,  TCP/IP  implementations  are  available  for  the 
VAX  at  a  relatively  lew  cost.  Using  the  Ethernet  as  the 
Local  Communications  process  and  with  TCP  available,  one  can 
envision  a  highly  respectable  testbed  for  the  SPLICE  module 
development.  Once  the  LAN  is  functioning  in  a  deferred 
mode,  the  interactive  traffic  capabilities  could  be  added. 


APPENDIX  A 
HIPC  CHARTS 

This  appendix  follows  the  HIPO  conventions  used  in 
ffief.  9]  and  [Ref.  11];  The  first  few  pages  consist  of 
Visual  Tables  of  Contents  (VTOC) ,  and  are  followed  by  the 
HIPO  charts  themselves.  The  charts  are  sorted  in  ascending 
numerical  order;  first  the  functional  modules,  then  the 
support  modules.  The  LAN  modules  other  than  National 
Communications  have  teen  included  for  the  sake  of  complete¬ 
ness.  Only  the  NC  mcdula  has  been  expanded  beyond  the  first 
three  levels  on  the  VTOC. 

During  the  development  of  these  charts,  it  was  found 
that  concurrency  was  very  difficult  to  represent,  since  HIPO 
was  designed  for  sequential  processes.  However,  the  HIPO 
method  has  proved  very  useful  in  the  functional  decomposi¬ 
tion  cf  the  modules. 
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AlrENDIX  B 

NC  ALGORITHMIC  BEPRESE STATION 

This  Appendix  is  a  pseudo  code  representation  of  the 
National  Communications  (NC)  Modules.  It  is  designed  to 
closely  conform  to  the  HIPO  diagrams  in  Appendix  A.  It 
provides  greater  detail  of  the  sequence  of  actions  cf  NC.  A 
sequential  execution  is  assumed  throughout;  however,  the 
Message  Server  (MS)  and  TCP  processes  are  expected  to  be 
communicating  processes  with  NC.  As  such,  MS  or  TCP  can 
execute  concurrent  calls  on  NC,  but  NC  is  not  interruptable , 
and  will  deal  with  each  call  in  turn.  The  code  dees  not 
describe  any  precedence  handling  constructs  or  methods  due 
to  the  sequential  execution  assumption.  To  add  precedence 
queues  will  require  a  determination  of  where  breaks  in  the 
sequential  flow  should  occur.  At  those  points,  the  sets  of 
precedence  queues  and  control  message  queue  should  begin. 
The  process  servicing  those  queues  would  always  choose  the 
highest  precedence  message  first,  and  would  choose  an  inter¬ 
active  message  before  a  deferzeu  one.  These  queues  and  queue 
servicing  mechanisms  appear  in  the  next  appendix,  but  they 
are  essentially  provided  by  built-in  language  constructs 
defined  for  Ada. 

A  mere  detailed  state  diagram  is  shown  in  figure  B.1  to 
provide  an  overview  cf  the  NC  pseudo  code.  Note  that  NC 
closely  fellows  the  state  changes  associated  with  TCP 
connections . 

This  design  does  suggest  some  possible  ways  NC  modules 
could  be  structured  tc  obtain  multitasking.  For  example,  the 
submodules  encapsulate  states  which  are  mutually  independent 
cf  one  another.  A  LAN  session  progresses  through  each  state 
and  can  cnly  exist  in  one  state  at  a  time.  This  implies  that 


Figure  B. 1  NC  nodule  Detailed  State  Diagram 


the  lower  submodules,  such  as  OPEN. Interactive. OUT,  could  be 
made  into  separate  processes  and  not  merely  subroutines  of 
NC  Hain.  In  fact,  multiple  copies  of  each  of  the 
submodules- -one  for  each  session-- might  be  implemented. 
Another  alternative  is  to  make  all  of  NC  reentrant. 
Appendix  C  attempts  to  depict  NC  using  the  Ada  language  as  a 
Systems  Design  Language  (SDL)  .  The  structure  uses  a  great 
degree  cf  concurrency  based  on  Ada  tasks. 
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This  appendix  was  included  so  as  to  outline  the  many 
details  associated  with  NC  actions.  It  should  provide  a  gcod 
initial  design  fcr  at  actual  implementation. 


A.  HC  MAIN 


Do  While  NC  Operate  =  True 
If  Message  Server  Call  then 

-  Interpret  LAN”MSG  (MSG  TYPE) 

-  Build/update  Session  Table  Entries 
Cass  MSG  TYPE  is 

Session  ABORT  ==>  Call  ABORT.  OUT 

Interactive  0 FEN  RQST  ==>  Call  OPEN. Interactive. OUT 
Deferred  OPEN  RQST  ==>  Call  OPEN  .Deferred. OUT 
1st  Deferred  Data  MSG  ==>  Call  ESTAB. Deferred. OUT 
Deferred  Data  MSG“==>  call  ESTAB. Deferred. OUT 
Interactive  D5ta  MSG  call  ESTAB. Interactive. CUT 

Deferred  CLOSE  MSG  ==>  Call  CLOS E. Deferred. OUT 
Interactive  CLOSE  MSG  ==>  Call  CLOSE. Interactive  .OUT 
Otherwise  ==>  Report  Error  to  Recovery  Management 
End  Case 
End  If 

If  TCP  MSG  CALL  then 

-  Interpret  TCP  MSG  (MSG  TYPE) 

-  Build/update  Session  Table  Entries 
Case  MSG  TYPE  is 

Error”MSG  ==>  If  TCP  Response  = 

"Connection  Reset" 

Then  Call  ABORT. IN 
Else  If 

TCP  Response  = 

"Connection  Aborted  due 
tc  User  Timeout" 

Then  Call  Error  Handler. IN 
Else  Call  Error  Handler. OUT 
End  If 

TCF  OPEN  Connection  RQST  ==>  Allocate  MSG  Buffer 

Issue  TCP  Receive 

Interactive  OPEN  RQST  ==>  Call  OPEN  .Interactive.  IN 
1st  Deferred  Data  MSG  ==>  Call  OPEN.  Deferr ed.  IN 
Deferred  Data  MSG”==>  Call  ESTAB.  Deferred.  IN 
Interactive  Dlta  MSG  ==>  Call  ESTAB .Interacrive. IN 
Deferred  CLOSE  MSG  ==>  Call  CLOS  E.  Deferred.  IN 
Interactive  CLOSE  MSG  ==>  Call  Interactive. CLOSE  .IN 
Otherwise  ==>  Report  Error  to  Recovery  Management 
End  Case 
End  If 
End  Cc 
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a.  OPEN. Interactive. ODT 


Issue  Active  Open  tc  TCP  (Initiate  Connection) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  OPEN 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 

Return  frcm  TCP  Active  Open  with  Local  Connection  Name 

Complete  Session  Table  Entries 

Issue  Send  to  TCP  (Interactive  OPEN  Request) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  SEND 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

Otherwise  = =>  Continue 
End  Case 

Allocate  MSG  Buffer 

Issue  Receive  to  TCP  (Prepare  for  Destination 
Acknowledgement) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  3uffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Manaqemenr 

-  Call  OUT.  ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 

Await  Interactive  OPEN  Acknowledgement  (from  destination 
process) 

If  Not  Acknowledged  by  Default  Timeout  then 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  "NC  Timeout" 

error  message  to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 

Return  frcm  TCP  Receive  (Interactive  OPEN  Acknowledgement) 


Issue  Iccal  Send  with  Interactive  OPEN  Acknowledgement  to 
Source  Message  Server 
Allocate  MSG  Buffer 

Issue  Receive  to  TCP  (Prepare  for  Session) 

Await  1CP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 
RETURN 


b.  OPEN.Interacti  ve.  IN 


Issue  local  Send  to  Destination  Message  Server  with 
Interactive  OPEN  Request  (Local  Connection  Name) 

Receive  Interactive  OPEN  Acknowledgement  (Local  Connection 
Name,  Session  Number,  Source  Addr,  Destination  Addr, 
Source  NC  Addr) 

Complete  Session  Table  Entries 

Issue  Send  to  TCP  (Interactive  OPEN  Acknowledgement) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  *>  Attempt  TCP  SEND 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
.End  If 

Otherwise  ==>  Continue 
End  Case 

Allocate  MSG  Buffer 

Issue  Receive  to  TCP  (Prepare  for  next  Message) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT.  ABORT 

-  Return 
End  If 

Otherwise  =  =>  Continue 
End  Case 
RETURN 
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2 .  Deferred 


a.  OP  E  N.  De  f  erred.  0  UT 


Issue  Active  Open  to  TCP  (Initiate  Connection) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  OPEN 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  R  etur  n 
End  If 

Otherwise  ==>  Continue 
End  Case 

Return  from  TCP  Open  (Local  Connection  Name) 

Complete  Session  Table 

Respond  to  Session  Services'  Message 

Allocate  MSG  Buffer 

Issue  Receive  to  TCP  (Prepare  for  session  message  acknowl 
edg<=ments) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Ola  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT.  ABORT 

-  Return 
End  If 

Otherwise  **>  Continue 
End  Case 
RETURN 


t.  OPEN.Def  srred.  IN 


Send  LAN  Message  to  Session  Services  (Precedence 
Classification,  Local  Connection  Name,  Source  Addr 
Destination  Adar) 

Receive  LAN  Message  from  Session  Services  (Loca 
Connection  Name,  Session  Number,  Source  NC  Addr) 

Complete  entries  in  Session  Table 

Issue  send  to  TCP  (Source  NC  Acknowledgement) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  SEND 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

Otherwise  -->  Continue 
End  Case 


Allocate  M$G  Buffer 

Issue  Receivl  to  TCP  (Prepare  for  session) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  RECEIVE 

at  least  two  mere  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OOT. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 

Issue  local  Send  (Session  Number,  Destination) 

RETORN 


ESTABLISHED 


1  •  Interactive 


a.  ESTAE.Interacti ve. COT 


Map  Session  number  to  Local  Connection  Name  in  Session 
Table 

Issue  Send  to  TCP  (Outgoing  LAN  message) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  SEND 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OOT. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 

Await  Acknowledgement  from  Remote  NC 

If  Net  Acknowledged  by  Default  Timeout  then 

-  Deallocate  Old  MsG  Buffer 

-  Send  LAN  message  with  "NC  Timeout" 
error  message  to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OOT. ABORT 

-  Return 
End  If 

Opdate  Session  Table 
Obtain  KSG  Buffer 

Issue  Receive  to  TCP  (prepare  for  next  message) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 


to  user 

-  send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 
RETURN 


b.  EST  AE.  Interacti  ve .  IN 


Map  Local  Connection  Name  to  Session  Number 
Verify  seauence  number  of  fragment/message 
Issue  Send  to  TCP  (Source  NC  Acknowledgement) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insuf f icient  Resources*' 

==>  Attempt  TCP  SEND 

at  least  two  mere  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT.ABORt 

-  Return 
End  If 

Otherwise  =  =  >  Continue 
End  Case 

Obtain  MSG  Buffer 

Issue  Receive  to  TCP  (prepare  for  next  message) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

Otherwise  =  =  >  Continue 
End  Case 

Update  Session  Table 

Issue  Local  Send  (new  message  number  assigned)  tc  Message 
Server 

RETURN 


2 .  Deferred 


a.  ESTAB. Deferred.  OUT 


Map  Session  number  to  Local  Connection  Name  in  Session 
Table 

Issue  send  to  TCP  (Outgoing  LAN  message) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  SEND 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 


-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  00T. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 

-  Await  Acknowledgement  from  Remote  NC 

If  Net  Acknowledged  by  Default  Timeout  then 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  "NC  Timeout" 
error  message  to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

-  Obtain  MSG  Buffer 

-  Issue  Receive  to  TCP  (Prepare  for  next  message) 

-  Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OOT. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 

-  RETURN 


b.  ESTAB.  Deferred.  IN 


-  Map  Local  Connection  Name  to  Session  Number 

-  Verify  sequence  number  of  fragment/message 

-  Issue  Send  to  TCP  (Source  NC  Acknowledgement) 

-  Await  TCF  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  SEND 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. ABORT 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 

-  Obtain  MSG  Buffer 

-  Issue  Receive  to  TCP  (prepare  for  next  message) 

-  Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  RECEIVE 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Deallocate  Old  MSG  Buffer 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 
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-  Call  OUT.  ABORT 

-  Return 
2nd  If 

Otherwise  ==>  Continue 
End  Case 

Update  Session  Table 

Issue  Local  Send  (new  message  number  assigned)  to  Messaqe 

Server 

RETURN 


CLOSE 


1  •  Interactive 


a.  CLOS  E.  Interacti  ve.  OUT 


Issue  Send  to  TCP  (Interactive  Close  Request) 

Await  Acknowledgement  from  Remote  NC 

If  Net  Acknowledged  by  Default  Timeout  then 

-  Send  LAN  message  with  "NC  Timeout" 

error  message  to  user 

-  Send  error  report  to  Recovery  Management 

-  Call  OUT. Abort 

-  Return 
End  If 

Return  from  TCP  Receive  (Interactive  Close 

Acknowledgement) 

Issue  Local  Send  with  Interactive  Close  Acknowledgement  to 
Session  Services  or  Source  Message  Server 
Issue  Close  to  TCP  (Terminate  Local  Connection) 

Delete  Entries  in  Session  Table 

Issue  Passive  Open  to  TCP  (Prepare  for  new  Connections) 
Await  TCP  Signal  (Response) 

Case  Response  is 

"Insurf icient  Resources" 

==>  Attempt  TCP  Passive  OPEN 
at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 
RETURN 


fc.  CLOSE. Interacti  ve.  IN 


Issue  Send  to  TCP  (Source  NC  Acknowledgement) 

Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  SEND 

at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Call  OUT. Abort 

-  Send  error  report  to  Recovery  Management 

-  Return 
End  If 


Other  wi 
End  Case 
Issue  Close  to 
Send  LAN  Messa 
Delete  Entries 
Issue  Passive 
Await  TCP  Sign 
Case  Respo 
"Insuif 


se  =  =  >  Continue 


Otherwi 
End  Case 
RETORN 


TCP  (Termi 
ge  tc  Sessi 
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If  still  sa 

-  Send  LAN 

to 

-  Send  err 

-  Return 
Ena  If 

se  ==>  Cont 


nate  Local  connection) 
cn  Services  to  delete  Session 
on  Table 

(Prepare  for  new  Connections) 

e) 

urces" 

TCP  Passive  OPEN 
two  more  times 
me  error  results  then: 

message  with  TCP  error  messaae 
user 

or  report  to  Recovery  Management 


inue 


2 .  Deferred 


a.  CLOS E.  Deferred.  OUT 


Issue  TCP  Send  (Deferred 
Return  from  TCP  Receive  ( 
Issue  Close  to  TCP  (Termi 
Delete  entries  on  Session 
Issue  Passive  Open  to  TCP 
Await  TCP  signal  (Respons 
Case  Response  is 

"Insufficient  Reso 
==>  Attempt 
at  least 
If  still  sa 

-  Send  LAN 

to 

-  Send  err 

-  Return 
End  If 

Otherwise  ==>  Cont 
End  Case 
RETURN 


Session  Close  Message) 

NC  Close  Acknowledgment) 
nate  Local  Connection) 

Table 

(Prepare  for  new  Connections) 

e) 

urces" 

TCP  Passive  OPEN 
two  more  times 
me  error  results  then: 

message  with  TCP  error  message 
user 

or  report  to  Recovery  Management 


mue 


fc.  CLOS  E.  Deferred*  IN 


Issue  send  to  TCP 
Await  TCP  Signal  ( 
Case  Response 
"Insuf  f  icie 
=  =>  A 
a 

If  s 

-  s 

-  s 

-  R 

End 

Otherwise  = 
End  Case 

Issue  Close  to  TCP 
Send  LAN  Message  t 
Delete  entries  in 


(Source  NC  Acknowledgement) 

Respor.s  e) 
is 

nt  Resources" 
ttempt  TCP  SEND 
t  least  two  more  times 
till  same  error  results  then: 
end  LAN  message  with  TCP  error  message 
to  user 

end  error  report  to  Recovery  Management 

eturn 

If 

=  >  Continue 


(Terminate  Local  Connnection) 
Session  Services  to  delete  s 


Session  Table 


Session 


Issue  Passive  Open  to  TCP  (Prepare  for  new  Connections) 
Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  Passive  OPEN 
at  least  two  more  times 
If  still  same  error  results  then: 

-  send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 
RETURN 


AEOBT 


1.  AECRT.  OUT 


Purge  Session  Message  Fragment  Queue 

Issue  AECRT  to  TCP 

Delete  entries  on  Session  Table 

Issue  Passive  Open  to  TCP  (Prepare  for  new  Connections) 
Await  TCP  Sianal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

=  =>  Attempt  TCP  Passive  OPEN 
at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  message 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 
RETURN 


2  .  AEORT.  IN 


Purge  Session  Message  Fragment  Queue 

Sena  Control  Messaae  to  Session  Services  to  ABORT  Session 
Delete  entries  in  Session  Table 

Issue  Passive  Open  to  TCP  (Prepare  for  new  Connections) 
Await  TCP  Signal  (Response) 

Case  Response  is 

"Insufficient  Resources" 

==>  Attempt  TCP  Passive  OPEN 
at  least  two  more  times 
If  still  same  error  results  then: 

-  Send  LAN  message  with  TCP  error  messaae 

to  user 

-  Send  error  report  to  Recovery  Management 

-  Return 
End  If 

Otherwise  ==>  Continue 
End  Case 
RETURN 


F.  EBROB  HANDLES 


1 .  Errcr  Handler.OUT 


Case  TCF  Errcr  Response  is: 

"Precedence  not  allowed"  or 
"Security/ccmpartm ent  not  allowed"  or 
"Connection  illegal  for  this  process" 

==>  Send  LAN  message  with  TCP  error  message 
to  user 

-  Initiate  NC  OUT  Abort 
"Destination  Unreachable" 

==>  Send  LAN  message  with  TCP  error  message 
to  user 

-  Initiate  NC  OUT  Abort 
"Insufficient  Resources" 

=  =>  Repeat  TCP  invocation  (OPEN, RECEIVE  or 

SEND)  by  Calling  appropriate  Routine 

End  Case 
-  Return 


2.  Error  Handler. IN 


-  Send  LAN  Message  with  TCP  error  message  to  local  user 

-  Initiate  NC  IN  Abort 

-  RETURN 


APPENDIX  C 

NC  DESIGN  IN  AN  ADA  SDL 

This  Appendix  utilizes  the  Ada  programming  language  as  a 
Systems  Design  Language  (SDL)  to  express  a  possible  struc¬ 
turing  cf  the  National  Communications  (NC)  and  other  process 
modules.  Cne  of  the  key  reasons  for  this  appendix  is  to 
suggest  ways  of  building  a  multitasking  model  of  NC  and 
other  communicating  processes.  As  such,  the  Ada  SDL  model  is 
not  meant  tc  precisely  define  all  of  the  details,  such  as 
specific  parameters  cf  the  interfaces. 

Using  Ada  as  a  SDL  allows  one  to  build  a  multitasking 
design  that  is  net  dependent  upon  the  use  of  specific  oper¬ 
ating  systems'  synchronization  primitives.  The  design  is 
intended  tc  avoid  using  any  system  dependent  facilities,  and 
for  that  reason,  the  pragma  priority  was  not  used  in 
conjunction  with  precedence  handling.  The  tasking 

constructs  of  Ada  readily  allcw  one  to  build  precedence 
handling  queues  which  are  needed  in  several  SPLICE  modules. 
Server  tasks  were  used  to  make,  for  example,  the  task 
NATICNAL_COfJMUN ICATICNS  asynchronous  from  other  tasks,  such 
as  an  instance  of  a  task  type  OPEN_S E RVE REQUEUE. 

Provided  in  Figure  C.  1  is  a  graphic  representation  of 
the  key  tasks  in  the  design.  Figure  C.  1  is  patterned  after 
the  style  espoused  in  [Ref.  17].  it  is  visualized  that 
tasks  concerned  with  enforcing  precedence  will  utilize 
select  with  guard  constructs,  and  extensive  use  of  the  count 
attribute  tc  check  through  various  entry  queues.  Also,  one 
might  expect  that  most  of  the  tasks,  especially  these 
instantiated  from  the  task  types,  would  have  timecut  with 
terminate  alternatives.  With  the  right  utilization,  only  the 
minimum  number  of  tasks  would  be  active  at  any  time. 


Cne  must  note,  however,  that  there  are  a  number  of  unan¬ 
swered  questions  concerning  the  efficiency  of  Ada  tasks.  It 
was  net  the  purpose  of  this  appendix  to  force  the  actual 
implementation  of  NC  to  be  done  in  Ada.  Bather,  Ada  was  used 
as  a  SDL  tc  provide  a  very  flexible,  system  independent 
means  for  addressing  a  multitasking  scheme  for  the  NC  module 
and  its  submodules.  Ada  SDL  can  provide  a  consistent  and 
well  defined  tool  for  expressing  designs  that  may  ultimately 
be  coded  in  a  considerably  different  target  language. 


Figure  C. 1  He  Task  Graphic  Hepresentaticn 
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APPENDIX  D 

SPLICE  BESS1GE  FORMATS 


Flag 

Message  Type 
Date  and  Time 
Destination  Address 
Lcaical  |  Physical 

_ : _ i _ 

Source  Address 
Logical  |  Physical 
Message  Number 
Data  Length 

Data  (Response  String) 
Error  Check 
Flag 


Figure  C.1  LAN  Control  Message. 


Note  that  the  data  portion  of  the  control  message  is  present 
to  accomodate  a  response  string.  This  is  especially  useful 
when  the  control  message  is  the  result  of  an  error. 


it 


Flag 


Classification 


Cestination 

Address 

| 

Logical 

Physical 

Source  Address 
Logical  Physical 

Number  cf  Fragments 


Session  Number 


Message  Number 


Fragment  Number 


Services  Request 
Code 


Error  Check 


Flag 
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152 


Flag 

Message  Type 
Date  and  Time 

Precedence  Classification 

Destination  Address 
Logical  j  Physical 
Source  Address 


Logical  Physical 


Humber  of  Fragments 


Session  Number 


Message  Number 


Fragment  Number 


Acknowledgement  Session  Number 


Acknowledgement  Message  Number 


Acknowledgement  Fragment  Number 

Data  Length  Services  Requesx 

i  Code 

Data 


Error  Check 
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